MVC vs. MVP: A Hillbilly’s Journey

Yes, I know you’ve read this before so stop rolling your eyes and skip it if you’re not interested. I’m not coming at this from the perspective of an expert imparting knowledge but as a hillbilly who has ignored the question too long. And now that I have to dive into it for the book, all the vagueness that I’ve been able to shunt aside to a little corner of my brain has surfaced like a long-lost brother beggin’ for college money.

So since I work from home without a lot of peers, my options are to talk it out here or to my daughter, who cries when her favorite singer is kicked off American Idol.

Pre-requisite reading:

Martin Fowler on GUI Architectures
Martin Fowler on Passive View
Martin Fowler on Supverising Controller
Martin Fowler on Presentation Model
Jeremy Miller on the difference ‘twixt MVC and MVP

I’ve looked through a number of other links but these are the ones I feel provide sufficient background and are suitably authoritative. Plus, I don’t want to rehash the definitions of each pattern.

So as I was waxing eloquent on Passive View and Supervising Controller, the thought crossed my mind, "I’m not seeing a lot of difference ‘twixt these and my understanding of MVC. They have the same components and the diagrams look similar enough…"

Martin Fowler’s contrast between the two didn’t help much:

MVP uses a Supervising Controller to manipulate the model. Widgets hand off user gestures to the Supervising Controller. Widgets aren’t separated into views and controllers. You can think of presenters as being like controllers but without the initial handling of the user gesture. However it’s also important to note that presenters are typically at the form level, rather than the widget level – this is perhaps an even bigger difference.

The problem stemmed from the way I’d explained the difference in my recent presentations on MVC. Specifically, I said that in MVP, the entry point was the View (aka. the aspx page) while in MVC, it is the Controller. While this is technically accurate, I now think it’s a consequence of the *real* difference.

Another thing blocking my understanding was that I spent too much time reading the theory and not enough time just reviewing my own code. I’ve implemented Supervising Controller in a web app before and my tag cloud seems to think I’ve done some work in MVC recently.

If I had done that, it would have been quite a bit clearer. In the MVP patterns, there is a lot of synchronization and infrastructure code that is absent from MVC. The presenter and the view communicate back and forth a lot.

For example, consider a button click in an MVP web page. Being a nice, decoupled view, it would probably look like this:

protected void buttonFerment_Click( object sender, EventArgs e )
{
    _presenter.Ferment( );
}

That is, the view passes the request on to the specific presenter its wired up to. And the presenter in turn would do whatever it needs to, then go back to the view and ask it to update its UI.

Now let’s see what the button click event would look like in an MVC page…

…except that you wouldn’t actually see a click event in an MVC page. In fact, thinking back to the MVC projects I’m working on, the views don’t even have code-behind files.

MVC seems to favour a purer separation of the View and Controller. From Jeremy’s post above:

[In MVC, there] is typically little or no direct communication between the View and Controller.

Which is definitely not the case with the flavours of MVP. This also jibes with Chad Myers’ explanation on Twitter.

It sounds like the MVP patterns are better suited for stateful environments (or stateless environments that someone has gone to great efforts to make appear stateful). MVC is shinier for stateless environments because the controller can collect up the model, dump it to the view, then call it a day. The view doesn’t so much launch events as it does tell a front controller that it wants to do something. The front controller re-routes the request to whatever controller is supposed to do the actual work. (Thanks to Tom Opgenorth for helping me sort out that bit.)

Going back to my stock explanation of the differences, I said that the view was the entry point for the MVP patterns and the controller was for MVC. As I mentioned, this is accurate but it’s a consequence of MVC having the front controller. Events in MVP are handled by the same page that launched them. In MVC, they are handled "globally" by the routing engine (aka. the front controller).

Finally, Bil Simser summed it up best when he said

Mvc lets me focus on the business problem and not how to update a view

So my ultimate understanding of the difference is that it is based on how intimate the View and Presenter/Controller are. In MVP, they are cosy and familiar, like cousins. In MVC, they are cold and distant, like lawyers.

Thank ye all for your kind attention while I worked this out in my head. If it has been helpful to anyone else, that’s not my fault.

Kyle the Controlled Presenter

This entry was posted in ASP.NET MVC, User Interface. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Aim

    Awesome way to put it, cleared my mind like a clear day following a stormy night. Thanks a lot.

  • Kyle Baley

    @Robert,

    Authentication can be handled as you normally would expect in an ASP.NET app (assuming you don’t use the built-in login ASP controls). Accept a username and password and validate it. Then create a FormsAuthenticationTicket, an HttpCookie based on the ticket and add the cookie to the HttpContext.

    For authorization, there is now a built-in filter whose name escapes me but is something like AuthorizeFilter. Add that to any actions and they are automatically checked. Scott Guthrie’s post on either Preview 4 or 5 has details.

    @Jim

    Ya, that was the line of questioning that led to this post in the first place. Which is why I modified my stance a little to say the entry point argument is a consequence of the real difference. It’s an effect, not a cause, I think.

    An MVP framework that runs the action first isn’t so far-fetched. In the MVP app(s) I’ve done, all the view does to initialize things is create a presenter and pass itself to it. A framework that starts with the action isn’t so far removed from that.

    But then, if you’re building a web framework that runs the presenter action first, it’s not that big a stretch to just make it an MVC framework. MVP applied well to web forms because of the funkiness Microsoft put in to make it “state-based”. Seems to me that if you’re going to go through the trouble of creating an MVP framework for web apps, you’d just add to the confusion.

    It’s been a while since I looked at Jeremy Miller’s StoryTeller app but you should take a look at it. It used one of the patterns but I’m embarrassed to say I don’t recall which one. I want to say MVP but something tells me there is a front controller in there.

    Likewise for David Laribee’s Xeva framework.

  • Jim Cooper

    “The entry point is the code that runs first when you navigate to a screen.”

    Ah, I see.

    “I’m sure it applies equally well to forms application”

    Weeeellll, I’m not sure. In a WinForms app, if we discount .NET framework code, what runs first when you “navigate to a screen” depends on what that actually means. It might be field constructors or the form constructor (where I guess InitializeComponent() “creates” the View), if we’re using some sort of lazy approach to form construction, otherwise it will be code in one of the event handlers (or possibly some sort of overridden method?). Presumably something in a form Load event or similar will trigger some presenter or controller action. I don’t see an obvious reason why anything would be especially different for either pattern.

    I’m not completely convinced by your web app argument either. The entry points you give seem to be implementation details, rather than anything to do with the patterns in general. For example, surely it would be possible to write an MVP framework that ran a presenter action first? I’m afraid don’t follow why should that only be possible with controllers.

  • Robert

    Hi,

    I have previously worked with MVP pattern for my WinForms apps. Now I’m about to develop a new web site, and I am thinking about using MVC.

    Now, how does one deal with login and authentication using the MVC pattern?

    Also, is it still possible to use controls based upon viewstate, or does this break the MVC pattern?

    Kind Regards,
    Robert

  • Kyle Baley

    Jim,

    The entry point is the code that runs first when you navigate to a screen. I’m sure it applies equally well to forms application but from a web perspective, in MVP, the first piece of code that runs is the code-behind of your ASPX page. I.e. the view. It will usually create a presenter and pass itself to that presenter to initialize the request process.

    In MVC, the first piece of code that runs is a controller action. It hasn’t hit a view yet. The controller determines which view to render, then sends the model down to it.

    That’s why we say the entry point is the View in MVP and the Controller in MVC.

  • Jim Cooper

    “They *are* still variations on the same pattern”

    Exactly :-)

    “but different enough that it warrants knowing the details of each.”

    Sure, but that applies to variations on all patterns. It’s always right to consider the pros and cons of different methods.

    I believe this sort of thing varies over time, too. So you could consider MVP to be an “updated” MVC, because it’s no longer necessary to write what Jason called “traditional MVC”. A modern controller looks a lot like a presenter most of the time.

    As far as the real-life framework differences go, I’m not sure that’s not more an implementation thing than a pattern difference, although of course, there is always going to be *some* difference.

    And I still don’t know what you guys mean by “entry point” in this context :-)

  • Jason

    From my understanding, the fundamental difference between MVC and MVP is the relative complexity of the V, P and C in each pattern.

    In traditional MVC, the Controller connected one UI element, say a text box (the View in this pattern) to the model. The controller was tightly coupled and specific to the UI element (think “TextBoxController”), and extended to adapt to the model. This made the view behavior *very* lightweight, delegating most of the gesture interpretation (clicks, text entry, etc) to the controller. Also as a result, there were usually a large number of controllers in a traditional MVC app.

    In MVP, the Presenter aggregates the controller responsibilities into a “super controller” (or “supervising controller” as Fowler calls them). Also unlike the Controller in MVC, the Presenter is usually associated with multiple UI elements, and leaves more of the gesture handling to the view. In a nutshell, the presenter cares less about the specific form a view takes in the MVP model than the controller does in the MVC model.

  • http://sharpbites.blogspot.com alberto

    Really well put. It’s the best explanation of the two patterns (or one, whatever) I have read.

    Thanks.

  • Kyle Baley

    Jim,

    Funny you say that. When I first started looking into them, I was going to take the same stance. I.e. Why all the discussion on their differences instead of their similarities? They are, as you say, almost identical. On paper.

    When I considered how I’ve seen them implemented outside of the contrived examples peppering the interwebs, their differences really do come out. As I thought about the MVC apps I’m working on and the MVP app(s) I’ve done, they resemble each other only very slightly. The end goal, testability (and by extension, maintainability), is the same but the approach is actually different.

    They *are* still variations on the same pattern but different enough that it warrants knowing the details of each.

  • Jim Cooper

    “Entry point”? I’m not at all sure what you mean by that.

    IMO, the two patterns are damn near identical. In fact, I’ve always wondered why anyone bothered to separate them at all. MVP is just an slighter cleaner separation of layers, when it comes right down to it. MVC allows the model to talk to the view, MVP makes all communication go via the presenter. That’s always seemed like an allowable variation of the one pattern to me.

    Martin Fowler’s articles talk about controllers in MVC handling really low level UI events (mouse moves, button clicks etc), but I personally don’t think that’s a defining difference. Once upon a time, that’s how you had to handle UIs, but with modern frameworks that’s no longer necessary.

    I also think the fact that there is so much confusion about the differences argues for them being variations of one pattern, and it’s just nit-picking to separate them.

  • Kyle Baley

    Andy,

    Okay, I think I’m on your page now. I like the idea of native MVP support. Or at the very least, having a web application start out with some guidance the way the MVC template does. But then we get into subjective territory and the hillbilly tends to avoid unresolvable debates.

  • http://weblogs.asp.net/astopford Andy Stopford

    Kyle,

    Well since the entry point is different the pattern usage changes with it. It would be incorrrect to say it is the only change between the two patterns but you could say that difference is a summing difference.

    I agree MVP has a tighter link between view and controller\presenter since you can’t farm out difference ways in the same manner as MVC. That said Passive-View makes the view very light and dumb so you can overcome this (although true passive view in aspx is impossible but that’s another story).

    As you say the entry point is an effect of this integration but when choosing a pattern that point is all important.

    One thing I’d like to see is webforms use MVP natively, but that’s like herding tigers.

  • Kyle Baley

    @Andy I won’t dispute that the entry point is different in each of them. Like I said, that’s how I’ve been differentiating ‘twixt the two in presentations. But having read Fowler’s a few times over in the last couple of days, I don’t think that is the defining characteristic, is it? Otherwise, wouldn’t he just outright say “the major difference between the two is the entry point”?

    Instead, I think the core difference is the tighter interaction between the view and controller/presenter (and I really wish there wasn’t such a naming discrepancy). The fact that the entry point is different is a consequence of this.

    I haven’t tried this but would it not be possible to initialize an MVP pattern from the presenter?

  • http://weblogs.asp.net/astopford Andy Stopford

    Hi Kyle,

    Sure while the view has a closer tie in MVP than MVC the two patterns are not view centric, it is all about entry point.

    In MVC the entry point is the controller and in MVP the entry point is the view. In both cases the view can be (should be) both light weight and dumb. Passive-View for example is supposed to make the view very light weight, letting the controlelr do all the work.

    Which one you would use depends on your needs, MVP works well in winforms as that only has one entry point. MVC works well in web land as REST based approaches like MS-MVC or MonoRail map well to the controller entry point. MVP would also work well in web land and you can adapt the pattern to webforms fairly well if you still need the page as the entry point.

    Some more good links

    http://blogs.infragistics.com/blogs/tsnyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx

    and an example Supervising-Controller MVP from the Haack

    http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx

    Andy

  • suresh

    In MVP, they are cosy and familiar, like cousins. In MVC, they are cold and distant, like lawyers………This is the Punch line…..Great……..I really enjoyed your article

  • http://weblogs.asp.net/bsimser Bil Simser

    I’ve actually come to a pretty good approach that works well. I use PresentationModel with WPF, MVC for web apps, and MVP for SmartClients (WinForms). Works great and let’s me test the important stuff!