To better understand why we will ever need to use ASP.NET MVC instead of the traditional, user friendly ASP.NET WebForm’s to develop ASP.NET applications we need to look into some of its shortcomings and how they are addressed in ASP.NET MVC applications.
ViewState Load
ViewState maintains the state across postbacks; it requires that the data be transferred back and forth between the client and the server. The data that is transferred can become so large that it consumes a heavy bandwidth, thus creating poor response for the user.
Mix of Presentation and Application Logic
Code behind frequently modifies the Web Form controls and also includes the application logic. This approach of mixing the presentation and application logic together results in code that is difficult to maintain.
Limited HTML control
Since the server controls render themselves, this could often be different from the HTML we want generated, like the client id created for the server controls (though this shortcoming has been fixed in version 4.0) and the automatically generated JavaScript.
Hiding of the true nature of the web creates problems
As we know, HTTP is a stateless protocol. Webforms hide this fact by creating an abstraction for us. Thus Web Forms are an abstraction and are meant to be used as such so that developing a web application has the same experience as developing a Windows application.
Now let us see how ASP.NET MVC addresses these shortcomings
There is no ViewState Load
ASP.NET MVC generated pages do not contain any view state data so the size of such pages is much less than the same pages generated using the ASP.NET WebForm approach.
Does not Hides the true nature of the web
MVC does not hide the true nature of the web as a stateless protocol but still it provides a way to write code that is easier to maintain and that is free of complications.
Encourages to have More Control over the HTML
WebForms, while trying to abstract the fact that HTTP is a stateless protocol, does a lot of things hidden for us, like generating the JavaScript and CSS. If we create similar pages in ASP.NET MVC and WebForms and see the HTML source for the generated pages we will see that the ASP.NET MVC page does not change the control ids and there is no JavaScript and CSS generated while the similar WebForm page automatically generates a lot of JavaScript and CSS which we might not be aware of.
MVC architecture can be depicted by the following diagram
In the MVC architecture incoming requests are handled by the controller which works with the model, selects the view and prepares the View data which is rendered by the selected view.
In short MVC is separating three main responsibilities into three main layers.
- Business Logic -> Model
- Presentation Logic -> View
- Application Logic -> Controller
Please note that Application logic and Presentation logic are most of the times mixed together in the WebForm’s in the event handlers.
Creating an MVC application in Visual Studio
Let us understand some of the concepts in an ASP.NET MVC application first.
Controller: In MVC incoming requests are handled by the controllers. A Controller is a class inheriting from the built-in Controller class which implements the IController interface.
Action: Each public method in the controller is an action that can be invoked using a URL.
View: Accepts the data in the ViewData objects passed to it by the Controller and renders them.
Model: Objects that are passed between controller and view.
Routing System: maps the URL’s to controllers and actions (To decouple the URLs from the web pages and also makes the URL search engine freindly).
While creating an ASP.NET MVC application in Visual Studio we have two choices of templates to choose from.
ASP.NET MVC 2 Web Application template
This creates a sample application preconfigured with things like authenctication, styles and navigation.
ASP.NET MVC 2 Empty Web Application template
Create only the files and folders required by every ASP.NET MVC application.