[[ Model View Controller ]]

Model View Controller MVC is a time tested method of separating the user interface of an application from its Domain Logic.

Domain Logic: Sometimes called business logic. Domain Logic represents the calculations and data storage that form the core of the application. These are the reason for the applications existence.

The primary goal of MVC is to isolate UI changes and prevent them from requiring changes to the Domain Logic of the application.

The primary reason for this division is that the user interface and Domain Logic have different drivers for change and different rates of change. By making this separation, you can change the UI without touching the Domain Logic and vice versa.
MVC is sometimes confused with other patterns that have the same goal of separating user interface from Domain Logic, such as Presentation Abstraction Control.

Presentation Abstraction Control: A pattern for implementing user interfaces, based around the concept of a heirachy of cooperating agents.

MVC divides an application into three concerns:

• Model - Encapsulates core application data and functionality Domain Logic.
• View - obtains data from the model and presents it to the user.
• Controller - receives and translates input to requests on the model or the view.

The separation into three concerns is inspired by a information processing model where the controller represents system input, the model represents processing and the view represents the output of the system.

Model

The model encapsulates the functional core of an application, its Domain Logic. The goal of MVC is to make the model independent of the view and controller which together form the user interface of the application. An object may act as the model for more than one MVC triad at a time.

Since the model must be independent, it cannot refer to either the view or controller portions of the application. The model may not hold direct instance variables that refer to the view or the controller. It passively supplies its services and data to the other layers of the application.

See Domain Model and Transaction Script to organize Domain Logic.

Passive Model

With a passive model, the objects used in the model are completely unaware of being used in the MVC triad. The controller notifies the view when it executes an operation on the model that will require the view to be updated.

The passive model is commonly used in web MVC. The strict request/response cycle of HTTP does not require the immediacy of an active model. The view is always completely re-rendered on every cycle, regardless of changes. This may be especially true in PHP where no state is retained between requests.

Active Model

In the active model, model classes define a change notification mechanism, typically using the Observer pattern. This allows unrelated view and controller components to be notified when the model has changed. Because these components register themselves with the model and the model has no knowledge of any specific view or controller, this does not break the independence of the model.

This notification mechanism is what provides the immediate updating that is the hallmark of a MVC GUI application.


Presentation Model

The purpose of MVC is to separate UI from domain logic. In doing so, an MVC implementation typically develops a set of reusable classes for each of the concerns in the triad. Sometimes, data or behavior that firmly belongs on the user interface side of the division can conveniently be represented using the infrastructure of the model side of the division. Thus objects that would appear at first glance to be in the model are really part of the interface concern, that is the view and controller.
Some examples include scrollbar positions and column sorting.

This is sometimes called an Application Model and the pattern known as MMVC after the idea that there are two separate models.

View

The view obtains data from the model and presents it to the user. The view represents the output of the application.

The view generally have free access to the model, but should not change the state of the model. Views are read only representations of the state of the model. The view reads data from the model using query methods provided by the model.

With an Active model, the view can register itself to receive notifications when the model changes, and the view can then present a more up to date version of the model.
Sometimes generic reusable view components can be arbitrarily connected to the model in a process known as binding.

See Template View and Transform View for strategies of implementing views.

Template View: A template is a document typically HTML with embedded markers which are replaced, manipulated, or evaluated via a template engine API to produce an output document.

Transform View: A view that processes domain data element by element and transforms it into HTML.

Controller

The controller receives and translates input to requests on the model or view.
The controllers are typically responsible for calling methods on the model that change the state of the model. In an active model, this state change is then reflected in the view via the change propagation mechanism. In the passive model, the controller is responsible for telling the view when to update.

In MVC, The controller is NOT a Mediator between the view and the model. The controller does not sit in between the model and the view. Both the controller and the view have equal opportunity to access the model. The controller does not copy data values from the model to the view, although it may place values in the model and tell the view that the model has changed. see Presentation Abstraction Control where the control layer acts as a mediator between Presentation and Abstraction.

The word controller is overloaded with different meanings in various patterns. see what is a Controller Anyway There are several of these controller patterns: Front Controller A single point of dispatch for incoming http requests. Page Controller Controls the flow of logic of a single web page. Application Controller Controls the flow of logic of a single application.

Front Controller: A front controller presents a single point for a web server to interface with a web application.

Page Controller: A Page Controller is one object or file declaration designed to handle the request for one logical web page or action.

Application Controller: A centralized point for handling screen navigation and the flow of an application.

Because the popular MVC framework Java Struts from a PHP Perspective implements a combined Front Controller and Application Controller, some people assume that this is what is meant by the MVC pattern in the context of a web application. For the same reason, many descriptions of the Front Controller pattern on the web do not draw the distinction between a Front Controller and a Application Controller.

Relationships between components

View Controller Relationship

In traditional smalltalk MVC, views and controllers are tightly coupled. Each view instance is associated with a single unique controller instance and vise versa. The controller is considered a Strategy that the view uses for input. The view is also responsible for creating new views and controllers.

It is logical that views and controllers are strongly related, the input and output of an application is strongly related. In most GUI MVC frameworks, the view and controller are simply merged into one object. This is called Document View. The view and controller are combined as the view. The model becomes known as a document.
A passive model shifts more responsibility into the controller, as it must notify the views when they should update.

The modern web usage of MVC shifts even more of the traditional responsibilities of the view to the controller. The controller becomes responsible for creating and selecting views and the view tends to lose responsibility for its controller.
Sometimes responsibility for creating and selecting views is delegated to a specific object, this is known as the Application Controller pattern for web MVC and View Handler for GUI MVC.

The rigid request/response cycle of HTTP may make the Document View variant less popular in web applications than in GUI applications although the controller is still strongly related to the view. The HTTP request is handled by the controller, the processing to the model, and the response is handled by the view.

Model View Relationship

The view depends on the model. Changes to the model interface require parallel changes in the view.

It is very difficult to achieve a strict separation between the model and view. For example, consider the requirement “Show negative balances in red.” At first glance, this appears to be strictly an output requirement and a test might be placed into the view in roughly this form:

if balance < 0 then red

This would violate the separation of concerns in MVC. Upon further analysis it turns out that the real requirement is “show overdrawn balances in red” and the definition of overdrawn =balance < 0= should be placed in the model as that is domain specific. It is very easy for domain logic to migrate out of the model and into the view. Template View contains further discussion of this issue.

Model Controller Relationship

The Controller depends on the model. Changes to the model interface may require parallel changes to the controller.


Benefits of MVC

Substitutable user interface

Different views and controllers can be substituted to provide alternate user interfaces for the same model. For example, the same model data can be displayed as a bar graph, or a pie chart, or a spreadsheet.

Some examples: Read only UI Expert and novice specific UI Different human languages Alternate input mechanisms User specific themes Alternate output formats XML, HTML, etc Alternate form mechanisms HTML forms, XForms, PDF forms

User interface components

Because MVC demands that the user interface of an application be structured into a hierarchy of objects and defines a standard relationship between these objects, generic versions of these objects are possible. They are usually called user interface components and no modern GUI environment is without a full complement of them usually combining view and controller into a single object. WACT is an attempt to provide a similarly rich set of components for web development that maintain the separation between view and controller. components promote reuse and reduce the need for special subclasses. These are known as “pluggable views” in the smalltalk MVC literature.

Multiple simultaneous views of the same model

Multiple different views can be active at the same time. Each view simultaneously and independently presents the same information from the model. This applies more to GUI MVC than web MVC.

Syncronized views

The change propagation mechanism insures that all views simultaneously reflect the current state of the model.

Easier user interface changes

Changes affecting just the user interface of the application logic become easier to make.

Easier testing

With MVC it can be easier to test the core of the application, as encapsulated by the model.

Drawbacks of MVC

Increased complexity

If reading this page doesn’t convince of you the complexity of this pattern, consider all of the auxiliary patterns that co-occur with MVC.

Close coupling of views and controllers to model

Changes to the model interface require parallel changes in the view and may require additional changes to the controller. certain code changes become more difficult.

Potential for excessive updates

The change propagation mechanism can be inefficient when frequent model changes require many change notifications. This is generally not as much of a problem if a passive model is used.

Close coupling between view and controller
strict separation is difficult if not impossible.