While surfing for the differences between MVC (Model View Controller) and MVP (Model View Presenter) I found lots of confusion over the net. Also I found some differences between the two on some sites, but none of them have complete list of differences. Following is one attempt for compiling almost all the differences between the two patterns.
|Parameter||MVC (Model View Controller)||MVP (Model View Presenter)|
|Structure||View(UI), Model(Business Entities/Data), Controller(UI Business Logic/Request Handling)||View(UI), Model(Business Entities/Data), Presenter(UI Business Logic/Request Handling)|
|Supervisor||In MVC Controller is the supervisor for responsing requests from View, commanding/altering model for providing entities/data and decide the next view to display.||In MVP Presenter is the supervisor for responsing requests from view, commanding/altering model for providing entities/data and return user requested view.|
|Supervisor and View Decoupling||In MVC, Controller is coupled with View. Controller is invoking next view through it’s concrete class.||In MVP, Presenter is decoupled from view. Presenter talks to view via interface.|
|Supervisor and View Communication||In MVC, communication between View and Controller(Supervisor) is one way. View is triggering Controller actions, but Controller is not directly talking to view. It always go through the Model.||In MVP, communication between View and Presenter(Supervisor) is two way. View is triggering Presenter actions, and after processing the request Presenter updates View through interface.|
|View and Supervisor Mappings||Multiple Views can be mapped to single controller becuase Model is updating View.||One View is mapped to one Presenter only, because presentor is updating View through interface. So, Presenter must be aware about which view to update/create.|
|Flavors: Passive Model and Active Model||
Passive Model: Employed when Controller is exclusively updates Model. The controller modifies the model and then informs the view that the model has changed and should be refreshed. The model in this scenario is completely independent of the view and the controller, which means that there is no means for the model to report changes in its state. The HTTP protocol is an example of this. There is no simple way in the browser to get asynchronous updates from the server. The browser displays the view and responds to user input, but it does not detect changes in the data on the server. Only when the user explicitly requests a refresh is the server interrogated for changes.
Active Model: The active model is used when the model changes state without the controller’s involvement. This can happen when other sources are changing the data and the changes must be reflected in the views. Consider a stock-ticker display. You receive stock data from an external source and want to update the views when the stock data changes. Because only the model detects changes to its internal state when they occur, the model must notify the views to refresh the display.
MVC pattern is mostly used with Active Model, otherwise in Passive Model we are again introducing dependency between Model and Controller.
Passive Model: The View is as dumb as possible and contains almost zero logic. The Presenter is a middle man that talks to the View and the Model. The View and Model are completely shielded from one another. The Model may raise events, but the Presenter subscribes to them for updating the View. In Passive View there is no direct data binding, instead the View exposes setter properties which the Presenter uses to set the data. All state is managed in the Presenter and not the View.
Active Model: The Presenter handles user gestures. The View binds to the Model directly through data binding. In this case it’s the Presenter’s job to pass off the Model to the View so that it can bind to it. The Presenter will also contain logic for gestures like pressing a button, navigation, etc.
|Advantages||Supports easy maintainability and extensibility with Separation of Concerns. Easy to unit test Model, View and Controller at some extent.||Also supports maintainability and extensibility with true Separation of Concerns. View and Presentor is decoupled so easily unit tested, in MVC in some scenarios it is difficult to mock test View independently.|
|Usages||Best used for developing disconnected web applications. i.e. ASP.NET MVC, Struts and Java Web Platforms.||Best used for rich UI applications. i.e. Web Forms/Sharepoint, Windows Forms.|