13.7. Guideline: The Model-View Separation Principle

What kind of visibility should other packages have to the UI layer? How should non-window classes communicate with windows?

Guideline: Model-View Separation Principle This principle has at least two parts: Do not connect or couple non-UI objects directly to UI objects. For example, don't let a Sale software object (a non-UI "domain" object) have a reference to a Java Swing JFrame window object. Why? Because the windows are related to a particular application, while (ideally) the non-windowing objects may be reused in new applications or attached to a new interface. Do not put application logic (such as a tax calculation) in the UI object methods. UI objects should only initialize UI elements, receive UI events (such as a mouse click on a button), and delegate requests for application logic on to non-UI objects (such as domain objects).

In this context, model is a synonym for the domain layer of objects (it's an old OO term from the late 1970s).

View is a synonym for UI objects, such as windows, Web pages, applets, and reports.

domain layer object p. 206

The

Model-View Separation principle^[2] states that model (domain) objects should not have

direct knowledge of view (UI) objects, at least as view objects. So, for example, a

Register or

Sale object should not directly send a message to a GUI window object

ProcessSaleFrame , asking it to display something, change color, close, and so forth.

^[2] This is a key principle in the pattern

Model-View-Controller (MVC). MVC was originally a small-scale Smalltalk-80 pattern, and related data objects (models), GUI widgets (views), and mouse and keyboard event handlers (controllers). More recently, the term "MVC" has been coopted by the distributed design community to also apply on a large-scale architectural level. The Model is the Domain Layer, the View is the UI Layer, and the Controllers are the workflow objects in the Application layer.

A legitimate relaxation of this principle is the Observer pattern, where the domain objects send messages to UI objects viewed only in terms of an interface such as

PropertyListener (a common Java interface for this situation). Then, the domain object doesn't know that the UI object is a UI objectit doesn't know its concrete window class. It only knows the object as something that implements the

PropertyListener interface.

Observer p. 463

A further part of this principle is that the domain classes encapsulate the information and behavior related to application logic. The window classes are relatively thin; they are responsible for input and output, and catching GUI events, but

do not maintain application data or directly provide application logic. For example, a Java

JFrame window should

not have a method that does a tax calculation. A Web JSP page should

not contain logic to calculate the tax. These UI elements should delegate to non-UI elements for such responsibilities.

The motivation for Model-View Separation includes:

• To support cohesive model definitions that focus on the domain processes, rather than on user interfaces.

• To allow separate development of the model and user interface layers.

• To minimize the impact of requirements changes in the interface upon the domain layer.

• To allow new views to be easily connected to an existing domain layer, without affecting the domain layer.

• To allow multiple simultaneous views on the same model object, such as both a tabular and business chart view of sales information.

• To allow execution of the model layer independent of the user interface layer, such as in a message-processing or batch-mode system.

• To allow easy porting of the model layer to another user interface framework.