ASP.net : Webforms VS MVC

Hello to all the dot net developers out there , Hope you all are having a wonderful day !!!!

I thought I should write this post out because the question webforms or asp.net MVC will really keep every developer thinking on what would be the best fit when you are set to start a new web application. Remember one thing that MVC is not a new technology but it’s a new concept or approach that can help you to create web application. Even i had this dilemma when I wanted to start with a new project. Just because I had experience in webforms i decided to choose it over MVC. I went with MVC when i got the next project to start with. I believe every developer will come across this confusions when there are multiple options but mostly i have seen my colleagues also choosing webforms over MVC just because they had earlier worked with it and they feel much better and comfortable when working with webforms. For a moment all developers will definitely have a hesitation towards the MVC side. When I started with MVC i found it little bit difficult initially and gradually i started feeling that it’s much better and a new framework which needs few days to really understand how MVC works.

During my course of learning MVC I found so many factors that differentiates between a webform approach and a MVC approach. Later I realized that these differentiating factors itself will lead you to decide which one can best fit your project requirement.

What was wrong with asp.net?
Asp.net webforms when released was the best idea Microsoft could give you. Later when the web application became more familiar, the usage increased and user interactivity, speed and other factors made the people realizing that there are some weakness in asp.net.

1). Maintaining State (viewState)
The actual mechanism of maintaining state across requests (ViewState) often results in giant blocks of data being transferred between client and server. It can reach hundreds of kilobytes in many real-world applications, and it goes back and forth with every request, frustrating site visitors with a long wait each time they click a button or try to move to the next page on a grid. ASP.NET AJAX suffers this just as badly,1 even though bandwidth-heavy page updating is one of the main problems that Ajax is supposed to solve.

2). Page Load (page Life Cycle)
The mechanism of connecting client-side events with serverside event handler code, part of the page life cycle, can be extraordinarily complicated and delicate. Few developers have success manipulating the control hierarchy at runtime without getting ViewState errors or finding that some event handlers mysteriously fail to execute.

3). Limited control over HTML
Server controls render themselves as HTML, but not necessarily the HTML you want. Not only does their HTML often fail to comply with web standards or make good use of CSS, but the system of server controls generates unpredictable and complex ID values, which are hard to access using JavaScript.

4). False sense of separation of concerns
ASP.NET’s code-behind model provides a means to take application code out of its HTML markup and into a separate code-behind class. This has been widely applauded for separating logic and presentation, but in reality, developers are encouraged to mix presentation code (e.g., manipulating the server-side control tree) with application logic (e.g., manipulating database data) in these same monstrous code-behind classes. Without better separation of concerns, the end result is often fragile and unintelligible.

5). Untestable
When ASP.NET’s designers first set out their platform, they could not have anticipated that automated testing would become such a mainstream part of software development as it is today. Not surprisingly, the architecture they designed is totally unsuitable for automated testing.

Now that’s about webforms . That doesn’t mean that webform approach is totally weak. These drawbacks are found when compared with the MVC framework. Let’s see how MVC answers these issues or what’s in MVC that makes it better than webforms.

1). Separation of concerns and single responsibility principle.
This is one of the best feature a developer would love to have in his coding. He would definitely love to keep his code neat, tidy, clean, modular, readable and maintainable. Its extremely important that a class in the system has a well-defined job for itself. No class should try to more than one job or too many things. If it does that it would be difficult to maintain the class.

2). Full control over the rendered HTML.
MVC gives full control over the rendered HTML. In webforms many times the HTML that is rendered is more complex than what is really required and thus makes it difficult for the designers to style the controls.

3). Test driven approach (unit testing).
This helps us to do the unit testing very easily. Webforms are tightly coupled to session, viewstate, request and response objects because of which it becomes a bad candidate for unit testing.

4). Search engine optimizations and RESTful URL’s
Webforms url has .aspx extensions whereas MVC urls does not have any extensions and thus becomes very search engine friendly. for example it have urls like "http://localhost:8080/appname/customer/list" or like the ones you notice when browsing facebook. So effort needed for search engines to recognize you application becomes much easier.

5). No ViewState.
This one becomes a big relief in terms of performance during the request and response cycle. You might have noticed above how webforms handles viewstate and the consequences of that.

6). Better control over JavaScript and styles
Webforms may dynamically add so many JavaScript files to the application when some controls or third party controls are integrated with the application. For example when you integrate AJAX into you webforms you can see few ajax related script files getting included dynamically to your application. In MVC you can very well control and include the script files that are really needed.

7). No IsPostBack branches of code.
You can completely eliminate this additional branches on IsPostBack flag from MVC because MVC doesn’t support this flag. Instead it handles it in a different manner in the controller.

Here we come to an end of this article. I am sure this will really help many to have an idea about both webforms and MVC. I will still edit this article as and when i find some more informations.

Happy coding to all developers and Enjoy

You can read the same article from my blog here