MVC, MVP, Presenter Model

The whole issue is that the underlying framework or technology that you’re using may impose some constraints that require tweaking of the standard MVC pattern. Traditionally, in MVC, the controller is the object which handles requests, be they HTTP requests, system events, or user interface actions. It looks like this:

But in most GUI frameworks like Swing or SWT/JFace, it’s the actual user controls which get notified of requests. In this case, you should delegate the handling of user requests to the controller. Martin Fowler calls such a controller a “presenter.” How you handle this delegation can vary and there are pros and cons to each. For example, you can end up with GUI specific code in the presenter or you can end up with the view having to have a handle on the presenter depending on your approach.

The difference then between MVP and the “Presenter Model” as described by Fowler is simply where to store the current view state information. MVP stores it in the view:

While the Presenter Model stores the data in the presenter itself:

Again, there are pros and cons to each approach. For example, in the Presenter Model approach you have to somehow handle syncing the presenter object and the view object’s state.

In summary, these are simply variations of MVC, mostly applied to situations where the view gets the requests and you need to place to store view state. This occurs mostly in GUI code rather than web frameworks. These patterns can lead to many more classes than just stuffing everything into your UI, but the separation of logic is especially useful for unit testing and it’s a good idea to practice separation of concerns anyway.