The Model-View-Presenter Pattern in ASP.NET

Embedding logic in the presentation layer might be a quick way to cobble together a simple web page interface, but for large-scale systems, separating the logic from the display with the MVP pattern is essential


October 05, 2007
URL:http://www.drdobbs.com/windows/the-model-view-presenter-pattern-in-aspn/202300122

Writing the user interface of a Windows system is way too easy. Every new version of Visual Studio makes the task simpler and simpler through wizards and tools of every sort. Code-behind files in both ASP.NET and Windows Forms, but also to some extent in Windows Presentation Foundation (WPF), seem to suggest developers not to waste their time with design and stratification of software. A plain old ADO.NET query right in the code-behind class of a page attached to the handler of a Click event does the job. And it's effective, and it's quick. And it just works.

More generally, we're not far from truth if we say that user interface facilities encourage developers to put in the presentation layer more stuff and code than it reasonably should. As a result, the presentation layer operates as a catch-all for logic of other layers, mostly the middle tier, but often also the data access layer. Is this really bad? And, if so, why is it all that bad?

I'm the first in line who just doesn't bother to place an ADO.NET query in the Button1_Click event handler of a code-behind class — if that page belongs to a temporary site or is destined to stay up and running only for short time; for example, an ASP.NET page that lives the three months around a user-group meeting. But even copycatting a Web site project that does the same few and well-known things, an approach that provides simplicity and time-to-market, isn't a bad thing per se. So feel free to make use of SqlDataSource controls, Linq-to-SQL, and plain ADO.NET stuff. All rigorously done right in the code-behind.

But for large, durable, enterprise-class systems, it's all another story.

Here, stuffing code in the presentation layer that logically belongs to other tier is a mortal sin. Presentation and model are to be neatly separated and classes with some embedded user interface are really hard to test efficiently and safely. Not to mention the risk of code duplication and the inherent difficulty to evolve and enhance the system providing different views of same model. The Model-View-Presenter (MVP) pattern can be a significant help to rationalize the presentation layer.

MVP assumes a data model, a view class and some logic to coordinate the display of information to the user. The data model represents the entities in play. The view class knows about the user interface elements and is ultimately responsible for providing a user-consumable view for the data model. Pushing data into the view is the main task of the presenter. The presenter typically holds a reference to both the view and the model. The view receives input from the user and fires events to the presenter. The view doesn't know about the model. It receives data from the presenter according to the details of a contract in place between view and presenter. That's it.

How would you implement a MVP schema in your user interface?

For each page or Windows form you may have consider the following. As your first step, you define the interface that represents the view. It is the contract between view and presenter and the conduit of communication between the two. Here's an example:


namespace Samples.Basic {
    public interface IScreenView {
        DateTime Now { set; }
    }
}

The View interface mostly needs setters for properties since it just needs to show the model. The Presenter is a class responsible for getting any data to pass along to the view and it also provides one method for each action the user can accomplish on the screen.


public class ScreenPresenter {
    private IScreenView view;

    public ScreenPresenter(IScreenView view) 
    {
        this.view = view;
    }
    public void Initialize() 
    {
        view.Now = DateTime.Now;
    }
}

Upon initialization, the presenter receives a reference to the view and initializes the view by setting all of its public members in the contract. Hence, the view once received data takes the time to reflect that data in the real user interface — controls. Still feeling lost? Read on and consider an ASP.NET page with just one Label control in its user interface.


<asp:label runat="server" id="lblCurrentTime" />

Here's a code-behind class for this page that is respectful of the MVP pattern.


public class Samples_Screen : System.Web.UI.Page, IScreenView
{
    protected void Page_Load(object sender, EventArgs e)
    {
        ScreenPresenter presenter = new ScreenPresenter(this);
        presenter.Initialize();
    }

    public DateTime Now
    {
        set { lblCurrentTime.Text = value.ToString(); }
    }
}

Do you really think this is hard stuff? Sure, the example is straightforward, but the underlying ideas and models are the same regardless of the richness of the view. Where's the benefit? You neatly separate view from the logic behind. And can easily use the same logic of gathering data to populate a radically different user interface. For example, a classic ASP.NET and an AJAX user interface.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.