(This answer applies to web applications. For regular graphical interfaces, see What are MVP and MVC and what is the difference?
Traditional MVC for GUI applications
This does not apply to web applications, but here is how MVC has traditionally worked in GUI applications:
- The model contained business objects.
- The controller responded to interaction with the user interface and redirected them to the model.
- The view is "subscribed" to the model and is updated every time the model changes.
With this approach, you can have (1) several ways to update a given piece of data and (2) several ways to view the same data. But you should not let each controller know about all the views, or vice versa - everyone can just talk to the model.
MVC on the server
Rails, Django, and other server-side frameworks tend to use a specific version of MVC.
- The model provides approximately 1 class for each database table and contains most of the business logic.
- The view contains the actual HTML for the site and as little code as possible. Basically, these are just templates.
- The controller responds to HTTP requests, processes the parameters, searches for model objects and passes values to the view.
This seems to work very well for server-side web applications, and I was very pleased with it.
Client MVP
However, if most of your code is written in JavaScript and runs in a web browser, these days you will find many people using MVP. In this case, the roles are slightly different:
- The model still contains all the core objects of your business domain.
- A view is a layer of pretty dumb widgets with a little logic.
- The host sets up event handlers in the widgets of the view, responds to events, and updates the model. In the other direction, the facilitator listens for changes in the model, and when these changes occur, it updates the view widgets. Thus, the host is a bi-directional pipeline between the model and the view, which never interact directly.
This model is popular because you can easily remove the view layer and write unit tests against the host and model. It is also much better suited for interactive applications where everything is constantly updated, unlike server applications where you deal with discrete requests and responses.
Here are some background readings:
Google MVP + Event Bus
This is the new approach described in this video from the Google AdWords team . It is designed to work well with caching, standalone HTML 5 applications, and sophisticated client-side tools such as GWT . It was based on the following observations:
- Everything that can happen should happen asynchronously, so first create everything to be asynchronous from the start.
- Testing browser-based views is much slower than testing models and presenters.
- The data of real models live on the server, but you may have a local cache or a standalone HTML 5 database.
In this approach:
- The view is very dumb, and you can replace it with mock objects when doing unit tests.
- Model objects are simply simple containers for data, without real logic. You can have multiple model objects representing the same object.
- The host listens for events from the view. Whenever it is necessary to update or read from a model, it sends an asynchronous message to the server (or to the local cache service). The server responds by sending events to the "event bus". These events contain copies of model objects. The event bus passes these events back to various speakers who update the attached views.
So, this architecture is essentially asynchronous, it is easy to test, and it does not require major changes if you want to write a standalone HTML 5 application. I have not used it yet, but it is the next one on my list of things to try. :-)