[Asp.Net] Why Asp.Net MVC?

Problems with Asp.Net Web Forms

So when ASP.NET Webform was so successful, why Microsoft thought of creating ASP.NET MVC.The main problem with ASP.NET Webform is performance, performance and performance. In web application there are two aspects which define performance:

1. Response time: - How fast the server responds to request?.
2. Bandwidth consumption: - How much data is sent ?.

Response time issues

 Let us try to understand why response time is slower when it comes to ASP.NET Webforms. We did a small load testing experiment of Webform vs Asp.Net MVC and we found Asp.Net MVC to be twice faster.

Read more on how this test was done from here

Let us try to understand why ASP.NET MVC was better in performance in the above load test.Consider the below simple UI code and Code behind for that UI.
Assume the ASPX code has the below simple text box.

In the code behind you have written some logic which manipulates the text box values and the back ground color.

protected void Page_Load(object sender, EventArgs e)
{
            TextBox1.Text = "Make it simple";
            TextBox1.BackColor = Color.Aqua;
}

When you run the above program below is the HTML output.

If you see the HTML output by doing view source it looks something as shown below.

Now stop reading for a moment, close your eyes and think. Try to get answers to the below questions:

1. Is this a efficient way of generating HTML?. Do we really need to make those long server trips to get those simple HTML on the browser ?.
2. Can’t the developer write HTML straight forward, Is it so tough?

If you see for every request there is a conversion logic which runs and converts the server controls to HTML output.This conversion get’s worse and heavy when we have grids, tree view controls etc where the HTML outputs are complicated HTML tables. Due to this unnecessary conversion the response time is less.
Solution for this problem: “GET RID of CODE BEHIND”, fold your sleeves and work with pure HTML.

Bandwidth consumption

Viewstate has been a very dear and near friend of ASP.NET developers for past 10 years because it automatically saves states between post backs and reduces our development time. But this reduction in development time comes at a huge cost, viewstate increases the page size considerably. In this load test we found viewstate increases the page size twice as compared to Asp.Net MVC.
Below is the plot of the content length emitted from Webform and Asp.Net MVC.

The size increase is because of extra bytes generated from viewstate, below is the snapshot of a viewstate. Lot of people can argue that viewstate can be disabled but then we all know how developers are, if there is option given they would definitely try that out.



Solution for this problem: “GET RID of SERVER CONTROLS”.
Note: The rest of the three points down below are browny issues which have cropped up due to presence of code behind and server controls. But the main thing is always performance.

HTML customization

Now because we are salves of the code behind and ASP.NET web server controls, we have “NO IDEA” what kind of HTML can come out and how efficient they are. For example see the below ASPX code, can you guess what kind of HTML it will generate.

I am a panel

Will Label generate DIV tag or SPAN tag ?. If you run the above code below are the respective generated HTML. Label generates a SPAN , Literal generates simple text , Panel generates DIV tag and so on.

I am label
I am a literal
I am a panel

So rather than generating HTML using server controls how about writing HTML directly and taking complete control of HTML.
So the solution for this problem is “DO NOT USE SERVER CONTROLS” and work with direct HTML.
The other great benefit of working directly with HTML is that your web designers can work very closely with the developer team. They can take the HTML code put in their favorite designer tool like dream weaver, front page etc and design independently. If we have server controls these designer tools do not identify them easily.

Reusability of code behind class

If you watch any professional ASP.NET Webform project you will notice that code behind class is where you have huge amount of code and the code is really complicated.Now this code behind page class inherits from “System.Web.UI.Page” class. This class is not a normal class which can be reused and instantiated anywhere. In other words you can never do something as shown below for a Webform class:

WebForm1 obj = new WebForm1();
obj.Button1_Click();

Because the “WebForm” class cannot instantiate with out “request” and “response” object. If you have ever seen the “ButtonClick” events of “WebForm” they are as shown in the code below. From the code you can know how difficult it is to instantiate the same.

protected void Button1_Click(object sender, EventArgs e)
{
// The logic which you want to reuse and invoke
}

Solution for this problem: “GET RID of SERVER CONTROLS and CODE BEHIND”.

Unit Testing

As said in the previous section you cannot instantiate behind code straight forward it’s very difficult to do unit testing or I will say automation testing on the code behind. Someone has to manually run the application and do the testing.

Reference: http://www.codeproject.com/Articles/866143/Learn-MVC-step-by-step-in-days-Day