Development Trivial Pursuit: The difference between MVC and the different flavors of MVP

Posted by Jeremy Miller on November 1, 2007

You can happily go your entire career without knowing the textbook definitions of either pattern and churn out working software.  On the off chance that you’re training for some sort of Coding Trivial Pursuit, here’s my shot at explaining the difference.

My new teamate and I had a discussion a couple weeks back on design patterns for user interface and he was using the terms MVP and MVC interchangeably.  Being the obnoxious pedant that I am, I told him that they weren’t quite the same thing, but had to run to the train before I could explain.  Later, the discussion became a little more serious as we got into the details of our system.  My new coworker is familiar with the Passive View approach to Model View Presenter (MVP)  and was trying to frame the implementation of his new feature in those terms.  For a variety of reasons I’ve followed a Supervising Controller pattern in our WinForms client.  Once I explained the difference and spent a little time on the rationale behind my design decisions he was able to work inside the architectural conventions and make some beneficial suggestions.  In this case, understanding the differences between two outwardly similar flavors of the Model View Presenter design pattern turned out to be important.

While all variants of both MVC and MVP are an attempt to separate the various responsibilities of a screen into cohesive classes, they differ in the details.  In a classic Model View Controller architecture, both the View and Controller have a reference to the Model.  Both View and Controller “observe” the Model and directly manipulate the properties of the Model.  There is typically little or no direct communication between the View and Controller.

In a Model View Presenter architecture the Presenter (basically the Controller) communicates directly with the View and tells the View what to do.  The Presenter is also listening directly to events from the View and takes action when an event is raised from the View. 

If you’re peeking ahead to Acropolis, you’ll see yet a third way to split up responsibilities in a screen that’s neither MVC or MVP.  As far as I can tell, Acropolis is pushing a Presentation Model approach that effectively merges the “Model” and “Presenter” into a single Presentation Model (or hides the Model inside the Presenter).  In this case, the View is bound directly to the Presentation Model.  Whereas the Model in MVC/MVP is typically ignorant of the screen, the Presentation Model is fully part of the screen behavior and can expose screen specific properties like “TheSuchAndSuchIsEnabled” or “ButtonsAreVisible.”  The Presentation Model classes might completely wrap what would be the Model in an MVC/MVP architecture.  Microsoft’s name for this pattern is Model-View-ViewModel, which might be a more apt description anyway. 

 

Web vs. Thick Clients

The relationship between the View and Presenter in MVP is continuous and the state is generally in the View and/or Model.  Because of this, MVP is most appropriately applied to stateful screens like WinForms or Swing clients.  I’ve used both flavors of MVP with WinForms and been pleased with the results.  While there’s absolutely nothing in WinForms to encourage you to go down any kind of MVC or MVP approach, there’s not much stopping you from using MVP.  I don’t see any reason why you couldn’t do classical MVC with WinForms, but MVP seems simpler to me.

Web clients are a completely different story.  You can do MVP with WebForms like I wrote about way back when, but I’ve found it to be no better than an acceptable compromise.  On the other hand, you’ve no doubt seen a tremendous amount of buzz over Microsoft’s new MVC framework for web development.  As applied to web development, MVC means a linear cycle of:

  1. Get the request in some sort of Front Controller
  2. Select the Controller and method to call
  3. If required, handle the requested transaction
  4. Build the Model structure of the data to be displayed
  5. Pass off the Model to the View to render into HTML

In this case the Controller simply builds the Model and passes it off to the View for rendering.  No stateful interplay between the View and Controller, just a “hey, here’s the Model, see you later” from the Controller to the View.

 

 

If my explanations were worth anything, you should now be perfectly confident in your ability to get that last pie piece in the development version of Trivial Pursuit.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Design Patterns. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Lucas

    It was my understanding that MVC and MVP are one in the same, in that MVP was just Martin Fowler renaming a pattern to better suite his intent, while MVP is identical to MVC type two (as is known on the east coast, and to most java enthusiasts) MVC type two is essentially what struts uses, and the future ASP.NET MVC model will attempt to replicate.

    I have had trouble looking for what MVP was besides what fowler stated, until i came across MVC type 2.

    Anyways thanks for the insightful analysis on these patterns and what it all means.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Lucas,

    As far as I know, the term Model View Presenter was coined in this paper: http://www.object-arts.com/papers/TwistingTheTriad.PDF about the Smalltalk Dolphin application framework.

    And I *do* consider the two MVP variants to be different from MVC and each other. In the Passive View variant the View wouldn’t even be aware of the Model objects at all.

  • http://grabbagoft.blogspot.com/ Jimmy Bogard

    We tried using MVP in traditional, out-of-the-box ASP.NET. What a disaster. The View usually has to instantiate the Presenter (strike 1), the Presenter has to get called by the View during certain Page lifecycle events (strike 2), and the View usually has to make extra initialization calls to the Presenter before it’s valid (strike 3).

    Throw in 3rd party controls like Infragistics or ASP.NET AJAX, and we were fighting a losing and very one-sided battle against all of the control and page events.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Jimmy,

    I think of MVP in WebForms as a game of coding hide and go seek. Let’s see, which event handler in the 2 dozen possibilities is the right one…

  • http://www.vmajason.com jimbono

    Jeremy, Just curious on what are your views on applying MVP in WPF applications using XAML and the like? Have you tried the triad in that scenario?

  • Harry

    Thanks you for the timely post. I am working on my first WinForm project. I came from ASP.NET WebForm background. I got introduced to MVP by JPBoodhoo’s work. Now I’ve worked on both ASP.NET and WinForm, my feeling is that I now can see why Super Controller has some advantage over Passive Vew in WinForm application. Super Controller allows better synchronization between different parts of screen by using data binding. While in browser based model, pages are loaded frequently so this is not a big problem, but for WinForm widget synchronization can pose a challenge for Presenter.

    Are my observations correct? What are the reasons behind your decision to use Super Controller in your WinForm app instead of Passive View?

    Again, thank you for the great posts, though they are so long I hardly can keep up with them. …

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @jimbono,

    Sorry, but I’ve got to plead complete ignorance. From the outside looking in, I don’t see WPF/XAML changing the usage of the design patterns one single bit. I know that XAML lets you add a lot of declarative behavior in the markup itself, but the word on the street is that WPF is very hard to test and debug so far. In light of that, I’d say that “Humble Views” are just as important as always.

    @Harry,

    “Are my observations correct? What are the reasons behind your decision to use Super Controller in your WinForm app instead of Passive View?”

    I still use Passive View for smaller dialog boxes. I switched from Passive View because of the tediousness of the Passive View. I’m justifying the usage of Supervising Controller by doing quite a bit of testing through the UI itself. In the next BYO CAB post I’m going to explain how we test screen behavior with StoryTeller/Fit.

  • JIM

    If you’re peeking ahead to Acropolis, you’ll see yet a third way to split up responsibilities in a screen that’s neither MVC or MVP. As far as I can tell, Acropolis is pushing a Presentation Model approach that effectively merges the “Model” and “Presenter” into a single Presentation Model

    Doesn’t that defeat the purpose of the MVP pattern?

    But it seems to me you don’t speak to the purpose of the pattern in this piece. So I’m not sure if you’re using it for buzzword compliance, or to simplify software development. Ultimately, all the Presentation Model approach gives me is an insurance policy object which needs to know about WinForms buttons.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @JIM,

    The Presentation Model pattern is just a different way to structure a UI than the two MVP variants. If you follow the link I do talk about why you would choose that approach.

    “Ultimately, all the Presentation Model approach gives me is an insurance policy object which needs to know about WinForms buttons.”

    Not sure what you mean here at all. In the PresentationModel approach the “PresentationModel” class would NOT know about the WinForms buttons and would be a completely non-UI class.

  • Neil

    “You can do MVP with WebForms like I wrote about way back when, but I’ve found it to be no better than an acceptable compromise”

    Jeremy – We are just starting web conversion from Classic ASP to ASP.NET and are following an MVP approach so I am very interested in why you have come to the above conclusion. Maybe your experiences could help us with a good architecture for our web apps? – Regards Neil

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Neil,

    I describe it this way. When you do MVP with WinForms screens and write/unit test the Presenter first, the screen generally works right off the bat. In WinForms it’s easy to make the Presenter predominate and run all control through the Presenter.

    In WebForms the exact same workflow still requires some effort to find the right combination of event handlers and tweaking of the page flow. WebForms tries very hard to be WinForms, but the abstraction just breaks down. MVP will still work, but it’s not as smooth an experience as I think it is in WinForms.

    You might go find Igloo off of the Castle site for some examples.

  • http://www.codecomplete.de/blogs/xamlblog/ jpk

    I don’t think, that anybody would rely on good old MVC in sight of Acropolis, WPF or any other new presentation technology. Rethinking MVC as Model/View/ViewModel on the other hand will reshape the old pattern to a modern form. A comparison between MVP in your Version and MVVM will be most interesting ;-)

  • Mark Brackett

    Just to prove that no 2 developers can ever agree on what is MVP/C, here’s my $0.02.
    “Classical” MVC has the View talking to both the Controller and the Model (hence MVC, instead of VMC). The View receives input, calls the Controller to manipulate the Model, and then syncs its output directly against the Model. The Controller is (more or less) reusable, as it has no knowledge of the View.
    MVP, in contrast, should really be called MPV, as the View never accesses the Model. Instead, the Presenter both manipulates the Model, and tells the View how to display it. I don’t think it’s required that the Presenter listen directly to View events – the View can respond to widget events, and call the appropriate method on the Presenter. You can even have some logic in the View to decide what method to call, or what parameters to pass, etc (same as MVC). The Presenter is tightly coupled to the View now, but the Model is not.
    Once you start trimming logic out of the View, you’re moving into Passive View, or Supervising Controller. Those variants mainly boil down to how much the View is responsible for.
    Passive View (an MVP variant) is all about testability, and keeps View code to the bare minimum – the Presenter does everything.
    Supervising Controller allows you to have declarative or very simplistic databinding within the View, and delegates the complex view logic to the Controller (along with it’s other responsibilities). The fact that the View is directly accessing the Model (via databinding) means it’s a variant of MVC (albeit, with some Presenter logic thrown into the Controller).

  • Jiho Han

    Yeah… I’m still confused about MVC vs MVP. Can you blame me really?

  • Hendry Luk

    Re Mark explanation,
    It’s weird that the first notion of MVC is about Controller being the king of everything. Meaning that the user talks to controller, then controller directs the view that to do.
    Therefore, view doesn’t talk to controller. It’s controller talking to both view and model. But view may talk indirectly to controller through observer (controller observes view).
    While in MVP, view is the king as it responds to user’s request, then direct the controller what to do.
    Re jeremy about the those statements that MVC’s view is stateless and MVP’s view is statefull. Doesn’t it just depend on the platform it’s runing on? MVC on winform will always be stateful (instead, smalltalk, the first implementation of MVC, is stateful). Just curiouslly, how do you implement MVC on winform?

  • IntiativeZer0

    Excellent article, thanks a Mil!

  • Antony Booth

    The Controller doesn’t ‘talk’ to anyone. In MVC, the controller configures the model, based on the business model of the action, determines the view to present and that’s it. The View uses the model, created by the Controller to perform UI behavior and maybe perform further actions that are once again performed by the Controller. It’s a simple architecture really. The Controller prepares the Model and doesn’t care what the view does with it.

    MVP is similar to MVC, but think of the Presenter as being a Controller that also has event handlers for the UI (Button Click for example) and other methods that are UI specific. It doesn’t actually have event handlers, but all the logic the event handlers would contain. An aspx page btnSave_Onclick(…) would contain little more than: Presenter.Save(); and the Presenter would handle the Save process. This allows multiple UIs, such as Windows forms and web pages, to all handle the Save click with the same Presenter logic.