MVC vs. MVP

Source: http://www.darronschall.com/weblog/archives/000113.cfm

By now you should've heard of the Model-View-Controller design pattern. If you've read OOP with ActionScript by Branden and Sam then you're also somewhat familiar with the Model-View-Presenter design pattern. So what's the difference?

MVC came first. With the MVC pattern it's possible to separate your presentation information from your behind the scenes business logic. Think along the lines of XHTML/CSS and separating your content from your presentation. A brilliant concept that works quite well, but is not without it's faults.

In MVC, the model stores the data, the view is a representation of that data, and the controller allows the user to change the data. When the data is changed, all views are notified of the change and they can update themselves as necessary (think EventDispatcher).
MVP is a derivative of MVC, mostly aimed at addressing the "Application Model" portion of MVC and focusing around the observer implementation in the MVC triad. Instead of a Controller, we now have a Presenter, but the basic idea remains the same - the model stores the data, the view is a representation of that data (not necessarily graphical), and the presenter coordinates the application.

In MVP the Presenter gets some extra power. It's purpose is to interpret events and perform any sort of logic necessary to map them to the proper commands to manipulate the model in the intended fashion. Most of the code dealing with how the user interface works is coded into the Presenter, making it much like the "Application Model" in the MVC approach. The Presenter is then directly linked to the View so the two can function together "mo' betta".

Basically, in MVP there is no Application Model middle-man since the Presenter assumes this functionality. Additionally, the View in MVP is responsible for handling the UI events (like mouseDown, keyDown, etc), which used to be the Controllers job, and the Model becomes strictly a Domain Model.