MVC v/s MVP, which one’s your favorite?

This is one of the most pretended question that comes  in technical interview and the way to look at it varies from condition to condition.

When looking beyond the RAD (drag-drop and configure) way of building User Interfaces that many tools encourage you are likely to come across 2 design patterns called Model-View-Controller and Model-View-Presenter.

MVC is a fundamental pattern which has been tweaked quite a bit to fit into various platforms. For instance if you had asked anybody how to implement an MVC in ASP.NET (prior to release of ASP.NET MVC framework) you would get very different answers. So let’s start with basic. The common motivation behind both is separation of concerns, cutting flab from UI (good for UI designers), swapping UIs (for instance windows to web), make UI easy for Unit Testing, etc.

MVP Pattern

Three components. But dependencies change (look at arrows in the diagram). Over here we replace Controller with Presenter (one which presents the changes done in model back to view). The main difference between both is that Presenter refers back to the view while Controller doesn’t. Normal pattern found here is to create an abstraction of the View (in terms of properties / events) & Presenter refers to it. This makes the mocking of View much easier & hence the Unit Testing aspect. Presenter here hence takes the responsibility of not only manipulating model but also updating the view. Of course the implementations of MVP differ in real world in terms of how much thin the view is, some prefer keeping basic logic still inside view & taking complex logic in presenter, while others prefer keeping the entire logic in Presenter. Martin fowler describes 2 variations on MVP on these lines namely – Supervising Controller & Passive View described below

 

• View is more loosely coupled to the model. The presenter is responsible for binding the model to the view.
• Easier to unit test because interaction with the view is through an interface
• Usually view to presenter map one to one. Complex views may have multi presenters.

MVC Pattern

Again Three components – View (your UI), Model (your business entities / data – that view is displaying) & Controller (contains the logic that alters the model depending on the action triggered by UI, typically implementing a Use Case). It’s widely known that MVC is a compound pattern (View and Controller have Strategy implementation, View itself can be a Composite implementation & View and Model are synched through Observer). In this case Controller doesn’t know anything about View, and the idea is that a View can switch Controllers (for instance depending upon who has logged to the system) & a single controller can be used by multiple Views. View subscribes to the changes done to the model & hence both are sync from the data perspective. One of the disadvantages of MVC is that it’s difficult to unit test. Controller manipulates the data but how about asserting those changes from a view perspective. For instance on click of a button you raise an event to controller, and controller modifies the value in model. This value modification changes the font size / color in View. Unit testing this scenario is slightly difficult in MVC.

• Controller are based on behaviors and can be shared across views
• Can be responsible for determining which view to display

 

Sr No	MVC	MVP
1	UI Presentation Pattern focus on separation of view with Model	Based on MVC (UI Presentation Pattern)
2	Separation of responsibility between three components: View - responsible for rendering UI elements Controller - responsible for responding to view actions Model - responsible for business behavior and state management	Separation of responsibility between four components: View - responsible for rendering UI elements View Interface - responsible for loose coupling between view and model Presenter - responsible for view and model interaction Model - responsible for business behavior and state management
3	The three components would interact with each other. Controller would sometime also be responsible to update view (like Front Controller Pattern)	Presenter can also interact with Controller to access Model
4	Fairly loose coupling	Comparatively high degree of loose coupling
5	Limited unit testing	Comparatively high degree of ease of unit testing
6	Identifies which view to update	Presenter will update its associated view

MVC and MVP in TDD

As stated already in this post, MVP biggest advantage is enabling writing presenter tests with only view interface available.On the other hand, MVC.NET approach to TDD offer much more power with providing ability of mocking the flow itself (you can mock context, request, response) + providing the controller based testing on a way similar to testing the supervising controller (setting the context DTO to desired values to trigger certain test flows).

Although that looks maybe to someone on first sight as an overkill. The simple nature of MVC route -> controller -> view makes writing complex web form tests much easier

I spent decent amount of time of this 2010 doing MVP tests in web forms and although there were a lot of hurdles during that time I face, I can not say that I felt too much pain mainly because I was mostly using  either front controller or application controller as MVP supplemental patterns

Right now, to me too MVC looks a little bit more complex to be TDD-ed and I don't know if the advantages of the MVP can be achieved easily in MVC too, but I realize that I don't have too much experience with real world TDD-ing MVC usage but I know that I can relay on Jeremy's opinion.

The promise of having easier TDD experience with MVC in upcoming period is making me very happy and really eager to dive deeper in MVC.

I will look forward to your comments .

Happy Coding..!!!