Home > Patterns > Choosing a UI Pattern (MVC, MVP, and ASP.Net MVC)

Choosing a UI Pattern (MVC, MVP, and ASP.Net MVC)

Recently I was interviewed by Microsoft (for Channel 9) about the MVC versus MVP versus ASP.Net MVC. During the interview I was asked how to decide when to choose a pattern or a framework when building .net applications. I found it a hard question to answer in words (I could only get out a basic explanation), so I want to try to answer it in writing (I am usually better at that). My answer to the interviewer was basically – it all depends on the amount of testing you want to do. The answer is correct, but it is a very generic answer (but I didn’t have much time to answer).

This particular post assumes you already know about the MVC and the MVP pattern. Of course they stand for Model View Controller and Model View Presenter. And the MVP is basically the MVC pattern, but it gives less control to the view and puts most of the responsibility in the presenter. It is an attempt to make all logic part of the presenter, thus the view is “passive”. The MVP pattern is even broken down into two other patterns, passive view and supervising controller, to even more decide on how much authority the view has. This post also assumes you at least understand the basics of the ASP.Net MVC framework (i.e.: it is a framework based around the MVC pattern). I am not going to explain the patterns or frameworks in this post as I believe that information is already widely available on the internet.

First of all, let me be clear – MVC and MVP are patterns and ASP.Net MVC is a framework around a pattern.

Also, let me be clear – this post is just my opinions, this is not any official way to think based off of Microsoft recommendations. These are just the opinions I have generated after buiding many sites with and without patterns and learning the “hard way” about why patterns are that important.

The first decision you have to make is – are you doing a winform or a webform. Unless you have a specific requirement for an application to be on the web, a winform or WPF is usually your best choice. A lot of companies are trying to do everything on the web now a days and I don’t agree with that. Deployment of winforms is easier than ever (with Click Once) and when working within a business domain environment a winform can be your best friend because of performance and ease of use. So, I will break down my recommendations first based on this.

I almost always choose the MVP pattern when building winforms. This provides me the best separation of UI from business as well as the best testability coverage of my view. Of course the MVP pattern is broken down into supervising controller and passive view. I tend to lean more towards the passive view, but I understand it is very restricting. If I have to do a lot of grid binding I see that the supervising controller can be a more flexible pattern, but you lose a little bit of testability that you would get with the passive view.

Very rarely will I recommend the MVC for a Winform application. The only times I will agree to this is if the timeline is very short and the initial setup of a good MVP pattern cannot be implemented in the time allotted. It is important to point out, a good controller pattern is key to a good system. So, if you don’t feel you can implement an MVP pattern, a MVC pattern will work just fine. At least you have testability over all your business function calls, by going through the controller, in this pattern.

Winform and Webform (cross-boundary application)
These are applications that need to be built to run on a web page as well as a winform. Good examples of these are applications where 100% of the functionality is available in house, on a winform, and 90% of the functionality is available on a webpage to external users. In these cases the MVP passive view pattern should always be used. The reason is the presenter is always responsible for everything. Thus, all you have to do is build respective UIs (that implement a particular interface) and you can resuse the whole M and P from the MVP model. It provides great reuse of code.

Webpages (in .net) can now be broken down into two separate things – WebForms(classic ASP.Net) and ASP.Net MVC. Deciding on which one to use depends on a few parameters.

It is important to understand that ASP.Net MVC is not a replacement for WebForms, it is just an alternative.

It provides a few great advantages:

  1. Built in MVC Pattern
  2. Front Controller pattern (implemented with Routing). Please note: routing is not an ASP.Net MVC pattern. It is a new functionality, of .net, that the ASP.Net MVC framework takes advantage of.
  3. Mock testing – using a Mock framework like RhinoMock, the ASP.Net MVC allows us to mock up website objects such as server, context, etc… This is a great advantage because we don’t have to have a website actually running to do our testing.
  4. No postbacks or viewstate. This really makes .net development more web-centric and really cleans up the html page that is ultimately created (because the viewstate is not in the webpage anymore)
  5. Great for Agile development. It really forces you to create end to end segments, one at a time.

However, it also has some disadvantages:

  1. Still in CTP – not even a beta release yet
  2. No postbacks or viewstate. Yes, I know I listed this as an advantage, but it is a disadvantage also. The reason is a lot of people have learned to work with postbacks and are going to have a hard time working without them.
  3. Controls support – controls that take advantage of postbacks or viewstate will not work. These include the grid control and the AJAX Update Panel. However, I am sure Microsoft will release similar controls for the ASP.Net MVC framework – eventually.
  4. Not great for design driven or waterfall development of large, business applications. Using something like an MVP pattern in a Webform will allow you to create interfaces and business layers completely before building any UI or View code. With ASP.Net MVC, you should create you views and test them from the beginning.

So, my conclusion to the question of “When to use ASP.Net MVC” is: use it in small to medium size applications when using agile development and when you need good test driven development. Or, use it if you are not a fan of the postback/viewstate implementation of WebForms.

WebForms (classic ASP.Net)
Webforms have not gone away now that ASP.Net MVC is here. It is still a very valid alternative. Before jumping into when to use this, a little history is in order. Microsoft built WebForms at an attempt to mimic Winform development. If you remember Classic ASP you will remember it was very hard, maybe impossible, to separate the business from the UI. So, Microsoft built WebForms to be more like Winforms. The business is seperated from the UI with code behind. Plus, it is an event-driven model, just like Winforms. When I say event-driven, I mean if you double click on a control it build an associated event in the code behind. It can do all this because of postbacks and viewstate.

When building a Webform you should still implement an MVC or MVP pattern. Preferably an MVP (supervising controller seems to work the best with Webforms) if you have enough time to build it out. You will be responsible for building this pattern out correctly however, so set some time aside in the beginning.

So, when should we still use Webforms:

  1. When you like the event-driven model. Having events behind controls is much easier for some developers to understand. If you don’t really understand how the web works, this hides a lot of that from you and can be easy to create web applications quickly.
  2. When you don’t care that much about testing. In these cases you probably won’t use any patterns, which I don’t agree with because I always think testing is important.
  3. When you need to use some of the more advanced controls that take advantage of postbacks and viewstate, such as the grid control and the update panel.
  4. When you want to build out business layers and interfaces before building UIs. Great for design teams to build in the waterfall methodology. You will have to incorporate an MVP pattern for this approach. This is usually done with very big business applications.

In conclusion:
Always use a well defined pattern to help with testing a system. The MVP is usually a good choice, when you are architecting from scratch, but the MVC is still a very good pattern. The difference between the two is just how much work the view is allowed to do. The MVP pattern attempts to take work away from the view. When building webpages in .net you now have two frameworks to choose from – webforms or ASP.Net MVC. When using the ASP.Net MVC you don’t have to worry about creating the framework for the pattern, it is built in for you. However, if you choose a webform, you should create a good MVP or MVC pattern around the work. Deciding on whether to choose a webform or an ASP.Net MVC application is a multi-facet question and has lots of considerations to think about. In the end, a general rule of thumb can be – use the ASP.Net MVC for small to mid size business applications where testing and agile development are important. Also, bear in mind the current control limitations when making this choice. Otherwise, use a webform and implement your own patterns.

Categories: Patterns
  1. April 5, 2008 at 9:46 pm

    Greg, I’ve been doing ASP.NET for some time, and have been getting into ASP.NET MVC lately. I was originally a PHP developer and have been developing for the web for a long time so it feels nice to have clean markup, no viewstate, and have the postbacks out of the way. But i have been struggling with seeing how really huge apps would be written with MVC. I think your comparisons regarding waterfall vs agile make good sense when comparing the the patterns.

  2. SamiFromParis
    July 18, 2008 at 12:57 pm

    Very good article.
    I’am architect on a projet (web application), and I Have to choose a solution to manage UI. I think that I’ll choose WebForms with MVP, is there a Framework to do this?

    Thank you

  3. Anu
    July 31, 2008 at 2:11 am


    I am unable to add custom aspx page in sharepoint site.. It is throwing error.

    See my OnPreInit()


    SPWeb myWeb = SPControl.GetContextSite(Context).OpenWeb();
    this.MasterPageFile = myWeb.Masterurl;

    Error says materpage “/_catelog.masterpage/default.master” not found..

    Your help will be appreciated…

  4. Steve Lian
    August 7, 2008 at 12:26 pm

    Hi Greg,

    I’m planning to integrate AJAX into my web application, and I know that ASP.NET MVC supports AJAX. Is it possible to use AJAX with MVP pattern? If it’s possible, could you give some guidelines.


  5. Greg Galipeau
    August 7, 2008 at 12:32 pm

    Hi Steve,
    Integrating AJAX can mean a lot of things. First, you have to consider which AJAX toolkit you want to use. If you are in the Microsoft world, I am guessing you want to use the AJAX.net toolkit. Second, you have to consider what parts of the toolkit you want. Most people love the UpdatePanel, but there are a lot of other parts to it.
    After those decisions are made your question can be answered by thinking about what AJAX does. AJAX calls to the Server and then “Callsback” to the Client side (rather than “Posting” back). Thus, the page doesn’t refresh. So, the MVC pattern works with how the Server side code interacts with the business logic. Thus, you can definetly incorporate this pattern with AJAX.
    Hope this helps,

  6. Steve Lian
    August 7, 2008 at 2:47 pm

    Hi Greg,

    Thanks for the quick reply. Basically, i will be using AJAX.NET toolkit with UpdatePanel in order to update each section of the page individually. In this case, how does MVC(or MVP) fit into the presentation layer of my 3-tier web application, i.e, i have developed BLL and DAL, each of these layers will be residing in separate servers?


  7. Greg Galipeau
    August 7, 2008 at 3:22 pm

    Hey Steve,
    I am not sure this question boils down to an AJAX.Net or regular webpage question. The concept of using AJAX.Net doesn’t really affect the UI patterns described. So, I will try to answer the question from a general “what is happening” point of view. However, it will be really hard to answer this in a comment – there are whole WhitePapers on the subject of how to implement these patterns correctly. But, I will give it a try 🙂

    We will stick to MVC for this question because it is harder to explain for MVP. Basically, any logic that you would normally put in your code behind file would be put into a controller. Then the controller could call out to your businsses layer. This way, UI logic is on the controller and Business Logic is in your BLL.

    An example of this is validation. Lets say you were doing validation on your code behind by overriding the validating methods of the code behind. In the MVC pattern that overridden validation method, in the code behind, would just be one line: Controller.Validate(). The controller will actually run that UI logic (or call out to the BLL if it is truely Business logic). Now you can also do things like implement interfaces or base classes for your controllers to force them to have methods like Validate. This way if anyone creates a new screen in your app and they use the Controller pattern, they will be forced to Validate their page. This is one small example.

    Another example people can associate with is Save. Your controller has the save method and the UI just calls controller.Save(parameters) to do the actually save. Maybe your save runs some other validation at this point, in the controller, and raises an event back to the view about what to do. Or maybe your save just calls out to your BLL from the controller. The point is, everything UI related is done in the controller. And, you can inforce this with the use of interfaces and base classes.

    Then, when you build testing into your application you can just instantiate controllers and call methods on the controller from your testing framework. That is the really simple answer to the question. There are lots of detailed examples on the internet (I don’t know one off the top of my head though, sorry).

    Basically, I like to think of these patterns as making your Views “stupid”. You try to make the views not do that much at all. This way, the testing framework can then work with the Controller (or Presenter for the MVP pattern) to do it’s testing. I like to think of the tests in these cases as the actual View.

    Now, the MVP pattern goes way more in depth than the MVC pattern, so I don’t want to try explaining it in a comment. But, the basic principal of it is that the View is even an interface and the presenter knows about the Views interface. Thus, the presenter tries to do everything for the View. This makes the View “really stupid” 🙂

    I know it is a complicated subject, but after using the patterns, you will never go back. I hope I did them justice in the explanation. Just remember, Ajax or not, it really doesn’t matter. Because, it is all about how the “Server” side code interacts with the Controller or Presenter.


  8. Steve Lian
    August 7, 2008 at 3:58 pm

    Hi Greg,

    Thanks for the explanations, it’s very clear and i got the whole picture of the design now. Again, thanks for the help, 😀


  9. October 30, 2008 at 12:38 pm

    Great overview!

    You might be interested in a Model View Presenter framework implementation for .NET – http://www.mvcsharp.org .


    Oleg Zhukov

  10. Lei Zhong
    December 2, 2008 at 4:58 am

    Hey Greg, I can learn a lot from opinions like yours which had to come from real world experience. Keep up the blogging – I know you are super busy, but this is very helpful for fellow developers.

  1. April 4, 2008 at 1:07 pm
  2. April 7, 2008 at 7:02 pm
  3. April 8, 2008 at 8:44 pm
  4. April 12, 2008 at 7:28 pm
  5. July 29, 2008 at 6:48 pm
  6. September 11, 2008 at 8:27 pm
  7. April 22, 2009 at 12:16 am
  8. September 8, 2009 at 3:09 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: