I come from a Java background where MVC pattern has been around since ever. There are tons of Java based web frameworks out there that implement the MVC pattern. It looked quite surprising to me that, till very recently there was no equivalent of MVC pattern in the .Net world. But, recently the things have changed, Microsoft has come up with its own implementation of the MVC pattern called Asp.NET MVC3.
I certainly like the MVC approach over the Web Forms approach for multiple reasons, I had to present these reasons to the client and convince them to move to Asp.Net MVC3 instead of the current Asp.Net Web Forms approach. Finally, after quite some talking and presenting and discussions we managed to convenience the client to adaopt the Asp.Net MVC 3 approach over the Web Forms approach.
This blog post highlights the points why I think, MVC makes a better choice as the presentation framework over Web Forms.
Separation of Concerns (SoC) And Single Responsibility Principle
If you ask me, what are the two most important principles which helps in keeping the code clean, modular, readable and maintainable?
My Answer would be, Separation of Concerns (SoC) and Single Responsibility Principle.
Its extremely important that every class in the system has a well defined job for itself. No class should try and do too many things, in fact it should do only *one* thing and do it well (Single Responsibility Principle). If one class tries to do too many things, then the code of the class would be messy, difficult to understand and maintain.
The code behind classes of the Web Forms approach are victim of this problem. Lot of times, I have seen the code behind classes are bloated and are longer than 2000 lines. Such classes are difficult to maintain and understand. The code looks convoluted.
Why does this happen?
Because, code behind classes have lots of responsibility. They deal with
- Showing the view
- Dynamically rendering JavaScript
- Updating the model
- Validating the values entered by the user
- Implementing some business logic
- Making a call to the service
- Differentiate the Post and Get requests etc.
MVC on the other hand, implements these principle very well.
- Controller classes are only responsible to update the model, decided which view to render and that's about it.
- Views only responsibility is to use the model to render itself.
- Model just holds the business realted information.
MVC gives full control over the rendered HTML
In the Web Forms approach, we were using third part controls called Telerik controls. At times its really difficult to control the HTML that gets rendered from these controls. Many times the HTML that is rendered is more complex than what would be required. Because of this, designers find it difficult to style it the way they want it.
With MVC, you get full control of the exact HTML that gets rendered. This is an absolute boon for the designers and developers
Unit Testing
I don't want to talk about how difficult it is to unit-test web forms code behind classes. The web form code behind classes are tightly coupled with things like Session, ViewState Request, Response etc. This makes them extremely bad candidates for unit testing. To unit test web forms code behind classes one needs a very strong will and extremely good mocking and Unit testing skills.
On the other hand, MVC has been build with Unit Testing in mind. One can easily do Test Driven Development with MVC controllers. Controllers are not coupled with Session or Request or Response object which makes them easily unit testable.
Search Engine Optimizations and RESTful URL's
Web Forms application URL's end with .aspx extension. They represent a physical file in the file system. The MVC URL's do not have any extensions. They do not logically map to a file on the file system. Instead they map to a controller and an action method inside the controller. The URL of MVC application look like
- http://localhost:8080/appname/customer/create
- http://localhost:8080/appname/customer/1
- http://localhost:8080/appname/customer/list
- http://localhost:8080/appname/customer/edit
Its difficult to integrate the web forms application seamlessly with a JavaScript library. For e.g. If you wanted to do Ajax with jQuery in a web forms application, imagine how much code you will have to write. How will you render the dynamic HTML in this case. How will you preserve the view state? Its all very messy.
With MVC, we do not have a problem like this ever. By default, MVC application comes integrated with jQuery. However, you could go ahead and integrate any other JavaScript library of your choice. Since view is not tightly coupled with controller integrating any JavaScript library is extremely easy.
No IsPostBack
I think there is no Asp.Net application in the world that does not have code which looks like
One class/method to handle both the get and post requests. At every step we have to decide whether its a get request or a post request and change the business processing.
This is infrastructure code. We should not be bothering about checking whether the request is a get request or a post request. Framework should do this for me.
With MVC, we do not have to keep checking whether its a get request or a post request. We can simply put an attribute to a method marking it only accessible via the GET request or only accessible via the POST requests. With MVC the above code would look like
Notice that we simply have to mark which methods are invokable over which protocol using either the HttpGet or HttpPost attributes. End result, simplified and easy to understand code.
No View State
Web Forms provides a wrapper over the stateless HTTP protocol to make it state-full. It achieves this by adding a hidden field called __VIEWSTATE__ to the rendered page. If not handled correctly and especially when you are using some third party control library like Telerik controls ViewState can easily get out of hands. I have see pages that have ViewState that goes in MB's. This ViewState will be sent/received to/from the server for every Post requests. Its sent/received to/from the server even when you do a Ajax request. The performance of such pages goes for a toss!
MVC has no concept of ViewState. MVC does not add a wrapper over the stateless HTTP Protocol. In fact it harnesses the HTTP protocol. Hence, MVC pages are much faster and they can easily out perform the Web Forms counter parts on any day.
These are some of the points why I think, MVC is definitely a better choice over Web Forms for building Customer Facing, fast Web 2.0 applications.
This list is by not means an extensive comparision of Web Forms vs the MVC appraoches. Just some little peaces which I though were really important.
We have made our choice to move to MVC, have you?
