Model View Presenter Pattern

One of the most popular sections of my Windows Forms Best Practices course on Pluralsight was the section where I described the Model View Presenter pattern.

It seems no one is interested in MVP these days, because if you’re doing server side web development you’ll probably be doing MVC, and if you’re writing WPF apps or SPAs (e.g. using Knockout.js), then you’re likely to be doing more of an MVVM pattern, where you use data-binding to communicate between the view and the model, and a “view model” to bridge the impedance mismatch between the two. Both these patterns are great, but I think the MVP pattern does still have something to offer for certain types of application.

So what is the Model View Presenter pattern, and why use it? Well basically, in Model View Presenter, you start off by making each of the UI components (in WinForms that would be user controls and forms) implement a view interface.

View Interfaces

The view interface should contain properties that allow the state and content of the controls in the view to be set and retrieved. It may also include events to report back user interactions such as clicking on a button or moving a slider. The goal is that the implementation of these view interfaces is completely passive. Ideally there should be no conditional logic whatsoever in the code behind of your Forms and UserControls.

Here’s an example of a view interface for a new user entry view. The implementation of this view should be trivial. Any business logic doesn’t belong in the code behind (and we’ll discuss where it does belong next).

interface INewUserView
{
    string FirstName { get; set; }
    string LastName { get; set; }
    event EventHandler SaveClicked;
}

One nice benefit of this approach over MVVM in WPF is that you don’t have to create complicated “behaviors” just to do simple things like setting the focus to a particular control on the form, or asking a listbox to scroll an item into view. Just add methods to do that onto your view interface, and the implementation can manipulate the UI component directly.

Presenters

Once you have made all your views passive and implement interfaces, you need something that will implement the business logic of your application and control the views. And these are called “presenter” classes.

The presenter’s job is to instruct the view what data to display. The view is also allowed to communicate back to the presenter. In my example above it does so by raising an event, but alternatively with this pattern your view can make direct calls into the presenter.

What is absolutely not allowed is for the view to start directly manipulating the model (which includes your business entities, database layer etc). If you follow the MVP pattern, all the business logic in your application can be easily tested because it resides inside presenter or other non-UI classes.

Obviously you do run the risk of your presenters getting overly complicated. In a real application, they will likely depend on other services and helpers which are doing the bulk of the business logic, leaving the presenter class to focus simply on “presenting” the data to the view, which is what it’s name implies.

Why Use It?

So what are the benefits of using? Well, one thing I like about this pattern is that it is very simple. It’s got a clear division of responsibilities and a new user coming to the codebase can easily understand and extend the pattern.

It also protects you from putting business logic in code behind, which is one of the main reasons a lot of WinForms applications are not easily testable and maintainable. And as I demonstrate in my Pluralsight course, it makes it very easy to migrate to WPF, since all you would need to do is implement the view interfaces again – all your business logic is reusable.

Demo Code

In my Pluralsight course, I demonstrated how to refactor a badly written Windows Forms apps into a better state. Unfortunately, time did not permit me to show anything more than the beginnings of an MVP pattern. But since so many people have asked to see a more developed example, here’s the demo application from that course, but refactored to use MVP more extensively. Of course, this is still a small application – for a real enterprise app I’d almost certainly introduce an IoC container to construct the views and presenters, and add in a framework for navigating between views. But hopefully this serves to give you some ideas for how you can begin to apply this pattern in your own applications.