Which pattern would you choose for web application and why?

Question

When you start a new web application, which pattern are you choosing between MVC and MVP and why?

Answer 1

Both MVP and MVC make sense and allow to separate logic from display.

I would choose MVC because it's widely used in web development these days (Rails, .NET MVC which is used for SO) so my application will be more easily maintainable by someone else. It is also -to me- cleaner (less "power" given to the view), but this is subjective.

Answer 2

Another alternative is MTV, Model-Template-View which Django uses.

Answer 3

(This answer is specific to web applications. For regular GUIs, see What are MVP and MVC and what is the difference?.)

Traditional MVC for GUI applications

This isn't really relevant to web applications, but here's how MVC traditionally worked in GUI applications:

• The model contained the business objects.
• The controller responded to UI interactions, and forwarded them to the model.
• The view "subscribed" to the model, and updated itself whenever the model changed.

With this approach, you can have (1) multiple ways to update a given piece of data, and (2) multiple ways to view the same data. But you don't have to let every controller know about every view, or vice versa—everybody can just talk to the model.

MVC on the server

Rails, Django and other server-side frameworks all tend to use a particular version of MVC.

• The model provides approximately 1 class per 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, it's just templates.
• The controller responds to HTTP requests, processes parameters, looks up model objects, and passes values to the view.

This seems to work very well for server-based web applications, and I've been very happy with it.

MVP on the client

However, if most of your code is written in JavaScript and runs in the web browser, you'll find lots of people using MVP these days. In this case, the roles are a bit different:

• The model still contains all the basic entities of your business domain.
• The view is a layer of fairly dumb widgets with little logic.
• The presenter installs event handlers on the view widgets, it responds to events and it updates the model. In the other direction, the presenter listens for changes to the model, and when those changes occur, it updates the view widgets. So the presenter is a bidirectional 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 presenter and model. It's also much better suited to interactive applications where everything is updated constantly, as opposed to server applications where you deal with discrete requests and responses.

Here's some background reading:

• Martin Fowler's encyclopedic summary of MVC, MVP and related approaches. There's a lot of good history here.
• Martin Fowler's description of "Passive View", a variation of MVP.

Google's MVP + event bus

This is a new approach, described in this video from the Google AdWords team. It's designed to work well with caching, offline HTML 5 applications, and sophisticated client-side toolkits like GWT. It's based on the following observations:

1. Anything might need to happen asynchronously, so design everything to be asynchronous from the very beginning.
2. Testing browser-based views is much slower than testing models and presenters.
3. Your real model data lives on the server, but you may have a local cache or an offline HTML 5 database.

In this approach:

• The view is very dumb, and you can replace it with mock objects when running unit tests.
• The model objects are just simple containers for data, with no real logic. You may have multiple model objects representing the same entity.
• The presenter listens to events from the view. Whenever it needs to update or read from the model, it sends an asynchronous message to the server (or to a local caching service). The server responds by sending events to the "event bus". These events contain copies of the model objects. The event bus passes these events back to the various presenters, which update the attached views.

So this architecture is inherently asynchronous, it's easy to test, and it doesn't require major changes if you want to write an HTML 5 offline application. I haven't used it yet, but it's next on my list of things to try. :-)