Before reading what ASP.NET MVC is, it’s better to understand why Microsoft has introduced MVC. Let’s try to understand this by comparing MVC and Webforms.
ASP.NET MVC vs WebForms
Success of Microsoft programming languages is due to RAD (Rapid application development) and visual programming approach. Visual programming was so much addressed and successful in Microsoft that literally they named their IDE’s as “Visual Studio”.
By using visual studio, developers where able to drag drop UI elements on a designer area and visual studio generates C# or VB.NET code for those elements. These codes where termed as “Behind Code” or “Code Behind”. In this code behind Developers can go and write logic to manipulate the UI elements.
So the Visual RAD architecture of Microsoft has Two Things.
What are the 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.
- Response time: – How fast the server responds to request?
- Bandwidth consumption: – How much data is sent?
Response time issues:-
Why response time is slower, when it comes to ASP.NET Webforms. Consider the below UI code and Code behind for that UI.
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox >
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;
See the HTML output by doing view source it looks something as shown below.
<input name="TextBox1" type="text" value="Make it simple" id="TextBox1" style="background-color:Aqua;" />
Now the points of discussion are:
- Is this a efficient way of generating HTML? Do we really need to make those long server trips to get that simple HTML on the browser?
- Can’t the developer write HTML straight forward, is it so tough?
For every request there is a conversion logic which runs and converts the server controls to HTML output. This conversion gets 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 get affected.
Solution for this problem: – “GET RID of CODE BEHIND”, means work with pure HTML.
Bandwidth Consumption Issue.
Viewstate has been a very dear and near friend of ASP.NET developers, because it automatically saves states between post backs and reduces our development time. But this reduction in development time comes at a huge cost as it increases the page size considerably.
The size increases, because of extra bytes generated from 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”.
In 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.
<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.
<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.
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.
Important Point to understand:-
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 without “request” and “response” object. If you have ever seen the “ButtonClick” events of “WebForm” they are as shown in the code below.
protected void Button1_Click(object sender, EventArgs e)
// The logic which you want to reuse and invoke
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.
How Microsoft Asp.Net MVC tackles problems in Web Forms?
This is the current WebForm architecture which developers are using in its 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 (DAL).
So Asp.Net MVC comprises of three sections Model, View and Controller(MVC).
- The code behind logic goes in to the controller.
- View is your ASPX i.e. pure HTML.
- Model is your middle layer.
So if you see there are two major changes VIEW becoming simple HTML and code behind moving to simple .NET classes termed as controller.
Asp.Net MVC request flow in general.
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 for the Model.
Step 3:- Fetched data filled in Model is then passed to the view for display purpose.