Battle of Two Patterns! MVP vs MVC
One day later, MVP pops up. MVP vs MVC.
Just a few days after I wrote my post about MVC, I came across a variation of it called MVP: Model, View, Presenter. This time around, the controller is replaced with the presenter which contains the UI business logic for the view, similar to how the controller “controlled” the logic and requests from the view to the model. Sometimes the view will delegate directly to the presenter, and sometimes it is decoupled and communicated through an interface. Thus, MVP vs MVC.
One way to think about it is in a situation where you send a request, but you also receive a confirmation message. When you submit a form, and press the “submit” button, the event handler will register the “OnSubmit” method. Once the form and request has been receive, there is a “two-way dispatcher” that will send a “SubmitCompleted” method back through the interface and the view will display that it was submitted, and maybe a confirmation message. The model does not know the view, but the view knows the model.
Furthermore, there are two variations to the MVP model. Passive View and Supervising Controller.
Passive View is where the “view” contains almost zero logic, and the presenter is the middle man that communicates between the view and the model. In this case, it prevents any communication between the view and model. There is no direct data binding from the model to the view, and instead the view will display what the presenter receives and sets. State is managed in the presenter. This can be preferred because it maximizes testing surface and there is a clean separation of the view and model which makes managing and organizing code relatively simple and straight forward. However, the annoyance can be increased work because it requires more manual data binding with the middleman presenter.
Supervising Controller is where the presenter handles user gestures. The view can bind directly to model through data binding instead of through the middleman presenter in the passive view model. The presenter passes model to view so that it can bind, which is what I suppose, would be the typical understanding of MVP.
With a short recap of MVC, the controller is different because it can determine the view depending on the action or request made by the view and model. The view is displayed in response to any action, including when the application loads for the user. It differs because in MVP, the actions are routed through the View to the Presenter, instead of the Controller to the View. In MVC, every action in View correlates with a call in the Controller and action. So a call to the URL, the controller will respond. Once the controller has processed, it will return the correct view.
Top: MVC – Controller handles user and commands model.
Bottom: MVP – View handles user and calls presenter as appropriate.
MVP vs MVC
MVC, the view does not bind to the model. View simply renders based on controller. The controller is dependent on behaviors and shared across multiple views. The controller is in charge, and is created or accessed based on some event/request from the user. It will then create or choose the appropriate view, interact with the model to further configure the view to display back to the end-user. As a result, the controller creates and manages the view, and the view is the slave to the controller. The view is not directly binded to the controller.
MVP, if view does not delegate to presenter, action will not happen. View is more loosely coupled to the model, and the presenter is responsible for binding the model to the view — one to one mapping. In a sense, you could see it as a direction of information and requests being made. View creates the presenter. The view is in charge as the presenter will interact with the model and manipulate the view through an interface. View knows about the presenter. View delegates to the presenter. Two way communication between view and presenter. View references to presenter, but not model.
3rd Variation: I wasn’t going to talk about this, but I had come across this a few times and even though it wasn’t the main point of discussion, I thought that I had might as well talked about it.
Not much to say about it, but in this variation there is no “presenter/controller” middle man in the web development architecture. Instead, the view binds directly to a “Presentation Model”, which is a model crafted specifically to work with the View. This isn’t as common because it kind of blurs the line on the traditional “model” definition. Thus the presentation model works by binding to the domain model and can be triggered for events from that model. The view binds to the presentation model, so it is similar to a train with doors and passageways interconnecting each train car. The presentation model essentially acts as the behavior for the view.