Mediating Logical View Logic

Mediating Logical View Logic

Capturing and extracting logical view logic might initially seem like an extra hurdle to perform at the cost of providing more indirection and bolstering the OO critic's accusation of lasagna type coding[1] designs. Lasagna coding comes with OOP; it is managed through generic implementations that promote a consistent implementation by all developers.

[1] Lasagna coding is a metaphor referring to the nature of OO designs that include many coupled methods and layers of object message execution sequences.

As earlier sections indicated, decoupling the user interface from the underlying domain implementation is accomplished by applying the MVC pattern; however, formalizing how controllers and view implementations interact with the domain provides further decoupling and supports the ability to interchange user interface technologies, along with some other benefits.

The formalization of view and controller interactions is accomplished through capturing requests and behavior made to domain objects in a separate layer. This layer provides a barrier between the presentation layer and the domain. Within the mediator layer, mediator objects are created for each specific application view. Mediator implementations define state and function used by view and controller implementations for a specific user interface. Figure illustrates the mediator and its place in the layered application architecture.

6. Mediator layer.


Mediators capture what can be considered interaction logic that is gleaned from user interface functionality. To help capture the spirit of mediator design, the following sections describe some examples of mediator-bound behavior.

1 List Support

All user interface technologies support some kind of mechanism to display lists of data. Table definitions and form lists are utilized to display dynamic HTML with JSP/Servlet technology. List and table controls are available in all operating systems as widget controls. List behavior is even used to support menu selections in a voice response unit.

Mediators define methods that reference and retrieve lists of domain objects. Mediators can also define convenience methods that extract and format properties of domain instances into collections that are accessed by the user interface. Figure illustrates this type of support.

7. Mediator supporting lists.


2 Selected Object

User interfaces are, in most cases, providing a user the ability to display or modify a domain instance. Mediators can define references to specific objects that have been navigated to through some kind of finding method or from a selection from a list of domain objects.

3 Communicating Validation Messages

Mediators also provide a convenient way to capture and format validation messages generated from the domain layer object. View resident logic, such as JavaScript, can validate formatting of data types and simple checks for the presence or absence of required fields. This is collectively referred to as syntactic validation. However, other, more complex types of validation rules, such as range value checks, are best defined in domain layer code.This placement allows these checks to be reused across application boundaries. Mediators can exercise these validation rules and capture their results, formatting them into ready to consume structures that view layer implementations can access consistently.

4 View Transition Support

Navigation between user interfaces often requires transferring values. Mediators provide a convenient and common object to carry out this transition. JSP/Servlet-based user interfaces can place object references in either session or request attribute objects that are available between interface transitions. Instead of allowing developers to put arbitrary objects in the session or requests, a generalized mechanism can be provided that supports mediator types. GUI-based interface transitions can apply a similar generalized mechanism that passes mediator references among panels, frames, etc.

This type of consistency eases maintenance by allowing developers to rely upon this pattern and structure. It also provides a place were other types of generalizations can be applied.

5 Collapsing Object Graphs

Java developers, when developing a user interface, often take Java object graphs and pull selected properties into some kind of user interface form for editing or viewing. In many cases, especially HTML-based interfaces, this means that Java data types are converted into strings for display. The same process is performed in reverse when values input into the user interface must be reconstructed into an object graph.

This type of logic is not necessarily coupled to a specific user interface technology; therefore, defining this logic within a mediator allows it to be reused across disparate interface technologies. Mediators essentially provide a façade interface between a user interface form and a domain object graph. Logic in the mediator can provide methods that perform the previously described pulling and pushing mechanism. Figure (on the next page) illustrates the role the mediator plays in collapsing an object graph for a user interface form.

8. Collapsing a user interface.


Mediators can act as a façade on business object graphs that are deep and require a lot of transformation prior to display. Defining this type of logic at the mediator layer allows other technologies to gain access to object graphs in an easier to use, linear structure.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows