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:
Built in MVC Pattern
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.
- 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.
- 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)
- Great for Agile development. It really forces you to create end to end segments, one at a time.
However, it also has some disadvantages:
Still in CTP – not even a beta release yet
- 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.
- 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.
- 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:
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.
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.
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.
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.
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.