MVC
Controller: Observer, takes input events.
View: Observer, presents data.
Model: Observable, holds data and data logic.
Synopsis:
Both Controller and View are registering at the Model as Obeservers. When a Controller makes a change to the Model, the View is synchronized by call of Update()s. This round-trip happens every time some input or data change occured. Traditionally a Controller is the actual widget.
Relationship:
A View is disconnected from a Controller.
Both View and Controller know about Model.
Good points:
When data has multiple views, such as multiple windows showing different aspects of the same data (e.g. input window, graph window, statistics window), each View is responsible for presenting in its own way, with the controller isolated from this mess. “Conversation” passes through the Model, with the help of the Observer pattern. Thus, a harsh separation.
Bad Points:
The View is very thin: no direct way of saving a GUI state for example.
MVP
View: Takes input, provides presentation
Presenter: Decides what to do with input, decides how to provide output to the Presenter.
Model: Holds the data and data logic.
*note: this is the “Ruby MVC” actually. Be ware that Controller is now Presenter, by Ruby naming.
Synopsis:
When a View takes input, it triggers an appropriate event to the Presenter, which knows about the View and takes whatever it needs, in order to perform a Model query. The Model returns data to the Presenter, and the Presenter is now free to shape it to the View’s need, and update the View.
The View knows about the Presenter, the Presenter knows about the Model, and the Presenter and View are separated.
Sometimes the Presenter modifies the View too. Traditionally a View is the form with all the widgets, and the Model and Presenter are logical entities.
Yet another variation:
Another important point to make is the Passive View. Here, the View is totally disconnected from the Model, and the Presenter is responsible to fill/synchronize the data to it. This is useful for testing purposes. That is actually what is done with the “Ruby MVC”.
Or in other words:
Sometimes the layers are arranged so that the domain layer completely hides the data source from the presentation. More often, however, the presentation accesses the data store directly. While this is less pure, it tends to work better in practice. The presentation may interpret a command from the user, use the data source to pull the relevant data out of the database, and then let the domain logic manipulate that data before presenting it on the glass. [Fowler02]
Good Points:
Solves the ‘Thin View’ problem. The View has a state, which the Presenter queries, and updates. It is also easier to maintain and understand than is usually the Observer pattern.
Bad Points:
An unorthodox separation of responsibilities on the expense of understandability.
*Model would mean domain model, set aside from the database model. With use of ORM, we rarely see the DAL, but get a set of domain model entities.
