Why should I use MVC?
- Test Driven Development support.
- Search Engine Optimization friendly URL by design (though now this is possible in ASP.NET 4 as well)
- No ViewState (this may seem a bit of moving backward to some), but overall a good design decision.
- Clean View Markup (no additional HTML emitted)
- 100% extensible. You can add your own controller, switch view engines at will, control model binding at wish etc.
- Rich UI support (possible through client side JS libraries like jQuery UI and others). Telerik has released some controls for MVC which includes Grid control as well (which are merely HTMLHelpers)
- Session, JS, Ajax works. Validation is even more powerful with DataAnnotations and jquery.
- Performance, faster.
- Full control over rendered HTML
- Pluggable architecture
Introduction to MVC
MVC is a programming architecture that aids developers with separating different components of an application
The Model
The model in an MVC application stores the application data or state of the application. The model is often a database, an XML file, etc. However, because the model is designed to encapsulate the data layer in the application, you will typically not see the data source correlated with the model with regards to MVC.
In an ASP.NET MVC application, the model typically uses LINQ to SQL or LINQ to Entities.
The View
The view is the user interface that your site visitors to see data from your model. In an ASP.NET MVC application, web forms (ASPX pages) are typically used to display the view, but there's a significant difference between an MVC view's page and a typical ASP.NET web form. Most specifically, an MVC view doesn't use the typical postback model and the page lifecycle that you are used to when using web forms doesn't exist with MVC views.
It's easy to make the mistake of thinking of the view as the component in MVC that handles user input and controls the interaction with the user. In fact, it's the controller that takes on this role. The view is strictly limited to displaying data from the model.
The Controller
The controller is responsible for handling the interaction with the user, for communicating with the model, and for determining which view to display to the user. The controller is derived from System.Web.Mvc.Controller.
The controller defines one or more actions that can be invoked using an URL entered into a web browser. For example, consider the following URL:
http://www.arvind.com/products/display/43
A request such as this one would be handed off to the ProductsController where the display action would be invoked. In this particular case, that action might then display a view of product number 43. The routing of the URL to a particular controller is configured using routes that are defined in the global.asax of the MVC application.
Asp.net MVC is slightly different from a normal asp.net application. In an ASP.NET Web site, URLs typically map to files that are stored on disk (usually .aspx files). These .aspx files include markup and code that is processed in order to respond to the request.
In MVC, Instead of mapping URLs to ASP.NET pages or handlers, the framework maps URLs to controller classes. Controller classes handle incoming requests, such as user input and interactions, and execute appropriate application and data logic, based on user input. A controller class typically calls a separate view component that generates HTML output as the response.
URL routing
The ASP.NET MVC framework uses the ASP.NET routing engine. We can define routing rules that the ASP.NET MVC framework uses in order to evaluate incoming URLs and to select the appropriate controller. You can also have the routing engine automatically parse variables that are defined in the URL, and have the ASP.NET MVC framework pass the values to the controller as parameter arguments.
MVC & Post backs
ASP.NET MVC framework does not use the ASP.NET Web Forms post back model for interactions with the server. Instead, all end-user interactions are routed to a controller class. This maintains separation between UI logic and business logic and helps testability. As a result, ASP.NET view state and ASP.NET Web Forms page life-cycle events are not integrated with MVC-based views.
MVC Project Structure
By default, MVC projects include the following folders:
- App_Data, which is the physical store for data. This folder has the same role as it does in ASP.NET Web sites that use Web Forms pages.
- Content, location to add content files such as cascading style sheet files, images, and so on. In general, the Content folder is for static files.
- Controllers.
- Models.
- Scripts, which is the recommended location for script files that support the application. By default, this folder contains ASP.NET AJAX foundation files and the jQuery library.
- Views.
MVC3 & Razor:
What is Razor?
ASP.NET MVC has always supported the concept of "view engines" - which are the pluggable modules that implement different template syntax options. The "default" view engine for ASP.NET MVC uses the same .aspx/.ascx/. master file templates as ASP.NET Web Forms. Other popular ASP.NET MVC view engines are Spart & Nhaml.
MVC 3 has introduced a new view engine called Razor.
Why is Razor?
- Compact & Expressive.
- Razor minimizes the number of characters and keystrokes required in a file, and enables a fast coding workflow. Unlike most template syntaxes, you do not need to interrupt your coding to explicitly denote server blocks within your HTML. The parser is smart enough to infer this from your code. This enables a really compact and expressive syntax which is clean, fast and fun to type.
- Easy to Learn: Razor is easy to learn and enables you to quickly be productive with a minimum of effort. We can use all your existing language and HTML skills.
- Works with any Text Editor: Razor doesn't require a specific tool and enables you to be productive in any plain old text editor (notepad works great).
- Has great Intellisense:
- Unit Testable: The new view engine implementation will support the ability to unit test views (without requiring a controller or web-server, and can be hosted in any unit test project - no special app-domain required).
Why do we use HTML Helper?
We can use HTML helpers to encapsulate some small HTML fragments which are repeated all over your pages. And to avoid writing those HTML snippets all over again you use helpers.