I create a simple Webforms MVP based form and also go through some of the advantages when using the MVP pattern compared to regular webforms.

This post describes some of the problems I have experienced when using regular webforms and the benefits of using an MVP framework.

Why I decided to try webforms MVP

The main reason I started looking at webforms MVP is that I’ve felt some pain points in working with standard webforms. The best idea in my mind would be to jump ship and use MVC instead, but sometimes you may find yourself stuck with legacy code and the switch to MVC would just be to big/costly leap.

A few problems i see with standard webforms:
- Hard to test.
- Hard to introduce IoC.
- Mixes presentation logic with application logic.
- Has a complicated page life cycle of events that you can get entangled in when your view starts to get complicated.

So when I was given a task of creating some new functionality in a webforms legacy application I decided to take a look at webforms MVP. I started with checking out the main webforms MVP site to download the framework and to look for examples, but when I started out, most of the documentation was noted “to be done” (this is starting to change now as documentation is starting to increase). So since there weren’t many examples to be found I decided to write a blog post with a basic example.

I won’t go into much detail on the MVP Pattern itself, there are already lots of sources to read about that. Instead I will dive into how to build a basic form using webforms MVP. To create this form I will use a user control which will implement my view, a presenter class to hold my application logic, and a model to pass data from my presenter to my view. The demo project I’ve created lists used cars in a table which can be filtered by a make and model dropdown.

The view interface inherits a webforms MVP interface called IView which contains the generic typed model. The view interface also contains an EventHandler for a custom event containing our selected id’s.

Our presenter class inherits from a webforms MVP base class with our View as generic type. When inheriting from this class we also need to pass in the generic typed view into the constructor. I also like to use dependency injection which is why i have my repository interface as a constructor parameter (Webforms MVP allows you to create a PresenterFactory to inject dependencies into your presenters, more on that later). In the constructor I also wire up my view events to my presenter events, which is where I update the model.

The ideal codebehind for a view is literally codeless, but when you use custom events, you might need to put a little bit of code in your codebehind to wire up events and values togeather. At least the codebeind only deals with view logic. Something you need to handle is to add the PresenterBinding attribute to your class and specify which presenter to use for this view. Here’s one of the differences between MVC and MVP. In MVC the controller gets called first and it selects it’s view but in MVP it’s the view that gets called first and it picks it’s presenter.

Dependency Injection

Webforms MVP also makes it easy to use dependency injection in your Presenters. You can create a presenter factory yourself or use the built in support for Castle and Unity or use Ninject, Structuremap or Autofac factories from the contrib project (link below).

The end result

The main reasons I prefer the MVP framework is that you can split application logic and presentation logic. I like having “dumb” views that just display model data, no more, no less. Another important aspect of MVP is that you get testable presentation classes. I have never bothered with testing webform pages or controls just because of the complexity, but now you have all the logic abstracted away in class you can actually test and mock properly.