There are already many posts on this topic and they mainly focus on why MVC is better.
I thought it might be helpful to explore the cons of using asp.net MVC and would like your input on this.
Let’s start with an overview…
As you may know, MVC is built on the Model-View-Controller pattern which has been adapted as a Model-View-Presenter pattern; the latter isolates the Presentation layer from the domain knowledge.
The Potel paper which defines MVP is here: http://www.wildcrest.com/Potel/Portfolio/mvp.pdf and Fowler has a good article here: http://www.martinfowler.com/eaaDev/uiArchs.html
The regular aspx model is based on a simple 1-1 request-resource relationship.
In essence, a URL maps to a file on disk. So, a URL request goes to the (IIS) web server which has a .aspx mapping which routes the request to .NET which calls the target page.
The page class inherits from System.Web.UI.Page which implements the IHttpHandler interface that defines the ”ProcessRequest()” method, which is the method called to get the output to send to the browser.
In the asp.net MVC framework, a controller handles an incoming request, so there is notion of an aspx page to service the request. A (single) Route Table, currently set up in the global.asax file, specifies which controller a request should go to. The routing mechanism is part of the .NET framework, outside the MVC dll. So, although MvcRouteHandler is the default one used, you can define your own controller. The RenderView() call on the controller is delegated to the ViewEngine; the default being WebFormViewEngine but you could use a third party’s.
The RenderView() is called on the ViewPage, which derives from System.Web.UI.Page. In turn, this calls the method (you guessed it) ProcessRequest, just like regular aspx.
Differences, Pros and Cons
So, what is the best model to create a web-site? It depends!!!
No, seriously, as with many architectural decisions, the choice is not about which technology is better but more about what is practical.
Here are some key differences to consider:
MVC provides indirection and abstraction between a URL and the processing rather than a URL mapping to an aspx page.
Most businesses prefer clean URLs; something like product/nivea/lotion is better than than product.aspx?brand=nivea&category=lotion. No more URL Rewriters.
MVC also abstracts the URLs from technology/implementation and you can switch out your back end without affecting the URL. Otherwise, you have to use ISAPIs or something to map your old URLs to the new implementation (a comon problem).
From a design standpoint, a view can cleanly service multiple URLs; with regular aspx, you had to add querystring parameters and switching logic to service multiple URLs from a single page.
MVC lends itself to some good object modeling and software design but the project needs to have someone who is skilled in that respect.
The regular model is easier to understand and I would recommend it for simple websites which have a known amount of URLs that are functionally independent. So, a company website is a good candidate.
A website with heavily data driven URLs would be better handled with MVC. A product catalog is a classic poster-child for MVC; a website with custom URLs for each user or a website serving images or other resources based on URLs would be good candidates; sites with co-branding (similar page structures and data) might be better serviced by MVC, where a URL pattern exists across brands, e.g. nivea/products/lotion and dove/products/lotion.
The MVC model provides extensibility at multiple levels; you can use your own controllers and view engines. In reality, you are most probably going to use the default engines but then there is no extra cost for this flexibility.
From a software design/architecture perspective, MVC lends itself to a clean and robust design and flexibility.
So, when would regular asp.net be a better choice?
The answer depends on:
- Requirements/characteristics of the website:
I think, if you have a website with URLs with fairly independent content, it might be faster and easier to use regular asp.net.
- Legacy codebase
If there is a legacy codebase and a running regular asp.net website, you better have a good reason for switching to MVC just to add features. This also involves an operational overhead for deploying the newer technology.
Also, if the current design needs to be reworked just to make it MVC, it may not be worth it.
If your company is a consulting shop that has to quickly deliver websites and you employ or outsource to consultants, MVC would add overhead to your delivery schedules and also hamper maintainability because the developers need to know what they are doing if you need to add controllers and views in the future.
An experienced developer will find MVC intuitive and easier to develop but a developer who has mainly worked in building websites and does not have software engineering skills might find MVC daunting and confusing especially after using regular asp.net for a while.
I am curious to hear your comments on this…