Billy McCafferty wrote a great article "Model View Presenter with ASP.NET." In it, he provides an approach to using MVP with ASP.NET, where we have views, presenters, and models, but we also have a view initializer. In ASP.NET, the view initializer is the ASPX page, and the views are the ASCX user controls.

The View Initializer (VI) knows about the View, the Presenter, and the Model. It is responsible for initializing views and page redirections. The VI declares the view(s) that implement their interfaces. The VI creates the Presenter, passing into it the view and the model, if needed. After passing the view to the presenter, the VI then needs to initialize the view (InitView()) to complete the MVP cycle.

Martin Fowler wrote, "Many people find that testing GUIs to be somewhere between tough and impossible. This is largely because UIs are tightly coupled into the overall UI environment and difficult to tease apart and test in pieces." As a result of this, I tend to lean towards using Passive View and the Humble Object approach when using MVP.

It is difficult to test views, and this is why it is important to delegate as much behavior to the presenter to make the view as dumb as possible. At the same time, it also becomes important to use interfaces for views so we can properly use them in unit tests and acceptance tests. As a result of this, I have been implementing MVP in projects recently, leveraging its testability.

MVP seems like a ton of extra work, and this can be a true statement. As we become more familiar, implementing it becomes easier. As we write our unit tests, we gain that return on investment.

Do not bother using MVP if you are not going to write unit tests. MVP promotes testability. If you are not taking advantage of this, then MVP is just extra work.

Read Billy's article, download his sample project, and write your own sample. MVP is a great design for ASP.NET applications.