MVC vs Code Behind

MVC vs Code Behind

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.

Hide   Copy Code

<asp:TextBox ID="TextBox1" runat="server">

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

Hide   Copy Code

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.

Hide   Copy Code

<input name="TextBox1" type="text" value="Make it simple" id="TextBox1" style="background-color:Aqua;" />

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.

Hide   Copy Code

<asp:Label ID="Label1" runat="server" Text="I am label">
<asp:Literal ID="Literal1" runat="server" Text="I am a literal">
<asp:Panel ID="Panel1" runat="server">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.

Hide   Copy Code

<span id="Label1">I am label</span>
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 favourite 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:-

Hide   Copy Code

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.

Hide   Copy Code

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.

What’s the solution ?

If we read the four issues mentioned in the previous section with ASP.NET Webforms the main culprit are two people “Code Behind” and “Server controls”. Below is root cause diagram I have drawn. In this I started with problems , what is the cause for it and the solution for the same. The complete diagram zeroes on two things “Code Behind” and “Server controls”.

The solution is we need to move the code behind to a separate simple class library and get rid of ASP.NET Server controls and write simple HTML.
In short the solution should look something as shown in the below image.

How Microsoft Asp.Net MVC tackles problems in Web Forms?

As said the code behind and server controls are the root cause problem. So if you look at the current WebForm architecture which developers are using it’s mostly 3 layer architecture. This three layer architecture comprises of UI which has ASPX and the CS code behind.
This UI talk’s with .NET classes which you can term as middle layer , business logic etc and the middle layer talks with data access layer.

So Asp.Net MVC comprises of three sections Model , View and Controller. The code behind logic goes in to the controller. View is your ASPX i.e. pure HTML and your Model is your middle layer. You can see in the above diagram how those layers fit in.
So if you see there are two major changes VIEW becoming simple HTML and code behind moving to simple .NET classes termed as controller.
In Asp.Net MVC request flow in general moves as follows:-
Step 1:- The first hit comes to the controller.
Step 2:- Depending on the action controller creates the object of the model. Model in turn calls the data access layer which fetches data in the model.
Step 3:- This data filled model is then passed to the view for display purpose.

Now that we have understood the different components of Asp.Net MVC let’s go in depth in to each one of these components , let us start doing some lab’s. Let us first start with controllers as they are the most important and central part of the MVC architecture.