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