Todd Snyder

UXG – Guidisan: Promoting Best Practices for Enterprise Development
MVC or MVP Pattern – Whats the difference?

Over the years I have mentored many developers on using design patterns and best practices. One question that keeps coming up over and over again is: What are the differences between the Model View Controller (MVC) and Model View Presenter (MVP) patterns? Surprisingly the answer is more complex than what you would suspect. Part of reasons I think many developers shy away from using either pattern is the confusion over the differences.

Before we dig into the differences let’s examine how the patterns work and the key benefits to using either one. Both (MVC & MVP) patterns have been use for several years and address a key OO principal namely separation of concerns between the UI and the business layers. There are a number of frameworks is use today that based on these patterns including: JAVA Struts, ROR, Microsoft Smart Client Software Factory (CAB), Microsoft Web Client Software Factory, and the recently announced ASP.Net MVC framework.

Model View Controller (MVC) Pattern

The MVC pattern is a UI presentation pattern that focuses on separating the UI (View) from its business layer (Model). The pattern separates responsibilities across three components: the view is responsible for rending UI elements, the controller is responsible for responding to UI actions, and the model is responsible for business behaviors and state management. In most implementation all three components can directly interact with each other and in some implementations the controller is responsible for determining which view to display (Front Controller Pattern),

Model View Presenter (MVP) Pattern

 

The MVP pattern is a UI presentation pattern based on the concepts of the MVC pattern. The pattern separates responsibilities across four components: the view is responsible for rending UI elements, the view interface is used to loosely couple the presenter from its view, the presenter is responsible for interacting between the view/model, and the model is responsible for business behaviors and state management. In some implementations the presenter interacts with a service (controller) layer to retrieve/persist the model. The view interface and service layer are commonly used to make writing unit tests for the presenter and the model easier.

Key Benefits

Before using any pattern a developers needs to consider the pros and cons of using it. There are a number of key benefits to using either the MVC or MVP pattern (See list below). But, there also a few draw backs to consider. The biggest drawbacks are additional complexity and learning curve. While the patterns may not be appropriate for simple solutions; advance solutions can greatly benefit from using the pattern. I’m my experience a have seen a few solutions eliminate a large amount of complexity but being re-factored to use either pattern.

 

·         Loose coupling – The presenter/controller are an intermediary between the UI code and the model. This allows the view and the model to evolve independently of each other.

·         Clear separation of concerns/responsibility

o    UI (Form or Page) – Responsible for rending UI elements

o    Presenter/controller – Responsible for reacting to UI events and interacts with the model

o    Model – Responsible for business behaviors and state management

·         Test Driven – By isolating each major component (UI, Presenter/controller, and model) it is easier to write unit tests. This is especially true when using the MVP pattern which only interacts with the view using an interface.

·         Code Reuse – By using a separation of concerns/responsible design approach you will increase code reuse. This is especially true when using a full blown domain model and keeping all the business/state management logic where it belongs.

·         Hide Data Access – Using these patterns forces you to put the data access code where it belongs in a data access layer. There a number of other patterns that typical works with the MVP/MVC pattern for data access. Two of the most common ones are repository and unit of work. (See Martin Fowler – Patterns of Enterprise Application Architecture for more details)

·         Flexibility/Adaptable – By isolating most of your code into the presenter/controller and model components your code base is more adaptable to change. For example consider how much UI and data access technologies have changed over the years and the number of choices we have available today. A properly design solution using MVC or MVP can support multi UI and data access technologies at the same time.

Key Differences

So what really are the differences between the MVC and MVP pattern. Actually there are not a whole lot of differences between them. Both patterns focus on separating responsibility across multi components and promote loosely coupling the UI (View) from the business layer (Model).  The major differences are how the pattern is implemented and in some advanced scenarios you need both presenters and controllers.

 

Here are the key differences between the patterns:

 

·         MVP Pattern

o    View is more loosely coupled to the model. The presenter is responsible for binding the model to the view.

o    Easier to unit test because interaction with the view is through an interface

o    Usually view to presenter map one to one. Complex views may have multi presenters.

 

·         MVC Pattern

o    Controller are based on behaviors and can be shared across views

o    Can be responsible for determining which view to display (Front Controller Pattern)

 

Hopefully you found this post interesting and it helped clarify the differences between the MVC and MVP pattern. If not, do not be discouraged patterns are powerful tools that can be hard to use sometimes. One thing to remember is that a pattern is a blue print and not an out of the box solutions. Developers should use them as a guide and modify the implementation according to their problem domain.

Posted: 17 Oct 2007, 17:08

Comments

Jess Chadwick said:

This is an awesome post.  I have definitely fallen into the category of developers you describe that shy away from using these patterns due to confusion of the differences.  I often look for diagrams that give a good representation of these patterns and I was never satisfied until now.  Thanks!

# October 18, 2007 1:54 AM

Mohammed Nour said:

Nice Post! But I still like this pattern - MVC originally - as I already worked on projects with an amount of complexity and I found how ASP.NET need this kind of pattern for building large scale projects.

Also in my opinion, MVP is a modification or a special case of MVC. I don't know why it's considered as a pattern on its own.

# October 19, 2007 5:27 AM

Devin Rader's Blog said:

Confused by MVC vs MVP?

# October 19, 2007 5:50 PM

Scott Dorman said:

Model View Controller vs Model View Presenter

# October 19, 2007 9:27 PM

Peter Hirzel said:

I learnt and used MVC from Smalltalk few years ago and developed many projects even in Java and C# based on this pattern. May be I will consider the MVP approach next time after reading this very interesting article...

What you say about the key differences seem to be very true for me too!

# October 26, 2007 8:11 AM

.NET Geek said:

The Model View Controller and Model View Presenter design pattern has been the source for a lot of confusion

# November 10, 2007 5:28 PM

Ross Hawkins said:

You down with MVC? Yeah you know me!

# November 11, 2007 4:16 AM

Develop Better said:

MVP vs MVC

# November 11, 2007 12:05 PM

David Kemp said:

This is an interesting post, but it does make the assumption that you're using Passive View (http://martinfowler.com/eaaDev/PassiveScreen.html) rather than Supervising Controller (http://martinfowler.com/eaaDev/SupervisingPresenter.html) as your MVP model.

With Supervising Controller, you still might still expose your model to your view (for example, for Data Binding), but the view still does none of the "heavy" work.

The other possibility is to expose Data Transfer Objects to the view, which only contain the data with the view is allowed to manipulate. John Paul Boodhoo wrote an interesting MSDN Magazine article using this  approach (http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx)

# November 12, 2007 4:02 AM

Charles said:

Thank you.  You have performed a much needed service with this post.

# November 29, 2007 12:33 PM

Fuzze! said:

Hi! Great post! actually a Very Great post! BUT now a cause for more confussion!!! Which to choose? How do u choose? Is one better than the other? Some help/advice and guidance!! please

# December 3, 2007 5:01 PM

Hosam Kamel said:

A nice article ex[;ain the difference between MVC and MVP patterns. read more here http://blogs.infragistics

# December 5, 2007 4:28 PM

Maor David said:

MVC or MVP? You've probably heard about Microsoft's new ASP.NET MVC Framework . MVC methodology

# December 8, 2007 8:49 AM

Tony Testa's World said:

ASP.NET MVC Framework (Delayed)

# December 9, 2007 2:20 AM

Devin Rader said:

ScottGu and Brad Abrams have announced the release of the first preview of the ASP.NET 3.5 Extensions.

# December 9, 2007 11:07 PM

Tony Testas World said:

ASP.NET MVC Framework (Delayed)

# January 1, 2008 9:21 AM

Mohammed Ashi said:

I agree with Jess Chadwick 100% very good detailed comment, man, you are genius.

# January 5, 2008 5:35 PM

Erwin Pant said:

The new ASP.NET MVC framework may be based on MVC but you have Web Client Software Factory (WCSF) that just released in Feb. 2008 and it uses the MVP pattern.  Makes me even more confused on which to use, although I like the idea that MVP is more loosely coupled.

# March 27, 2008 4:32 PM

Sanju said:

Nice Article

# April 23, 2008 1:30 AM

Marcus said:

It is a great article that tells a lot about ways to implement the MVP pattern, but it got me confused because MVC in this article looks a lot like MVP implemented as 'Supervising Controller'.

I read a great article that explains MVC as it was originally designed and shows the true added value of MVP.

http://aviadezra.blogspot.com/2007/07/twisting-mvp-triad-say-hello-to-mvpc.html

# April 27, 2008 7:13 AM

Andrew Stopford's Weblog said:

This question seems to get asked a lot, this recent article on codeproject does a decent job of explanation

# May 13, 2008 8:11 AM

Nancy Barness said:

8l8I37 Blogs rating, add your blog to be rated for free:

http://blogsrate.net

# June 23, 2008 9:18 PM

Khanh Luu said:

I kind of agree with Mohammed Nour. MVC is the generic pattern that everybody knows. About the MVP, it is a matter of using interface or not using interface, a design choice. If we add an abstract layer (interface), there will be overhead. But on the other hand, we gain loose coupling. So, MVP pattern is a child of the MVC pattern.

# June 24, 2008 10:18 AM

Sudhakar Chavali said:

Good Post.

# July 2, 2008 8:01 AM

Tilahun said:

Thank you very much, you get-out of me from confusion. Appreciated

# July 2, 2008 5:55 PM

infragistics said:

# July 16, 2008 9:14 AM

web-robertmao-5 said:

# August 4, 2008 3:00 PM

Ben said:

Cool article !!!

# August 6, 2008 1:34 AM

saraf uddin talukder said:

I kind of agree Nour. MVC is the generic pattern that everybody knows. About the MVP, it is a matter of using interface or not using interface, a design choice. If we add an abstract layer (interface), there will be overhead. But on the other hand, we gain loose coupling. So, MVP pattern is a child of the MVC pattern.

# August 12, 2008 1:53 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS