If you are an ASP.NET Web Forms Developer, you may have a hard time initially wrapping your head around how ASP.NET MVC works or is fundamentally different from ASP.NET Web Forms technology. Well, hopefully, my following brief explanation or summary of how everything fits together will significantly aid you in your understanding of ASP.NET MVC and thereby help you transition your existing applications over to ASP.NET MVC over from ASP.NET Web Forms.
Views (Presentation Layer)
Views in ASP.NET MVC are not fundamentally different from what we have used in the past for ASP.NET Web Forms. They are just basically an intermingling of ASP.NET Code along with HTML.
If we are using Views with the Razor syntax, the ASP.NET Code is essentially a new form of ASP.NET Data Binding expressions beginning with the @ symbol instead of <%# %> to make the syntax cleaner and more terse.
The fundamental differences you will see in declaring Views is that there is no concept of a code behind file nor is there any longer any concept of using Data Source binding. Instead, all the binding that is to occur in a View is called "Model Binding"
Let's start with how an ASP.NET MVC View works without a code behind file. In ASP.NET Web Forms, we tied everything to a Code Behind file and therefore all of our business logic resided in this file. However, an ASP.NET MVC View is even more loosely coupled in its presentation logic than an ASP.NET Web Form .aspx file. Instead, it is bound to a Controller. The Controller is responsible for returning the View as well as any Models to the View that will be used for binding. The Controller, in most scenarios, will need 2 methods for handling functionality present in ASP.NET Web Forms:
- An [HttpGet] method used to handle the traditional if (! Page.IsPostback) functionality we used to provide in the Page_Load event handler
- An [HttpPost] method used to handle any traditional Postback functionality we used to provide in our ASP.NET Code Behind file
The Controller is conventionally bound to the particular View by the solution structure and name. Therefore, a View in a SampleWidget folder, will be bound to a Controller named SampleWidgetController.
Also, as you can probably guess, since the Code Behind file no longer exists in ASP.NET MVC views, all of the ASP.NET Web Forms controls that we have grown to love are no longer available for us to use. Instead, we have to rely on the new features provided in HTML5 as well as Html Helpers to provide much of the rich functionality we used in the past with ASP.NET Web Forms. Fortunately, many 3rd party vendors such as Telerik, Infragistics, ComponentOne and many others have provided special controls that can be used in ASP.NET MVC applications. If you do not have the funding to purchase such 3rd party controls, you can find many suitable replacements to the ASP.NET Web Forms controls in the jQuery UI framework. The most jarring difference you will find in transitioning over to ASP.NET MVC, is that there is no concept of a server side event handler, therefore, most of your event handling logic will have to be processed and performed on the client side and then posted back to your Controller method. Once again, performing actions such as Validation can be facilitated through use of the jQuery Validation framework.
Now, as for Model Binding, the Model is used as the fundamental method for providing data binding functionality in ASP.NET MVC Views. Instead, of using Data Sources as we traditionally used in ASP.NET Web Forms, we are using these new sources of data called "Models".
Models (Data Binding)
Models are essentially classes that can hold the structure of your data. You can use Models as "ViewModels" which are basically transformation containers that differentiate between your existing database structure and the structure you actually need to present in your View or they can directly be Entity Framework classes. Depending on your requirements, you can use a mixture of the two to perform your "Model Binding".
As you have already probably guessed, you can no longer use things such as SqlDataSource controls in your Views because this would thereby cause your Views to be tightly coupled to your data or your data access methodology. Therefore, Views are instead bound to Models which makes your retrieval of data for presentation independent and more loosely coupled. After all, the whole point of using the ASP.NET MVC architecture is to provide a more flexible and loosely coupled application that makes it easier to Unit Test the individual components of your application rather than the very typical tightly coupled applications we developed using ASP.NET Web Forms technology.
Models can either be stored directly in the Models folder in your ASP.NET MVC solution structure or they can optionally be created as a separate .NET Class Library assembly and subsequently referenced in your project.
Controlllers (ASP.NET Code Behind Files)
Controllers are essentially where all the magic happens. As stated above, you will typically have at least 2 methods in your Controllers decorated with the [HttpGet] and [HttpPut] attributes. Of course, you can have more methods in your Controller that are responsible for forming the business logic for your views in the form of various private or protected methods, but the only 2 methods used to build and return the View are the ones decorated with the [HttpGet] and [HttpPut] attributes.
Controllers are essentially responsible for putting everything together and returning everything back to the View. If you need to do any sort of data access to populate your Model classes, you will perform all of these operations inside of the Controller. You can do any type of Data Access that you want in your Controller in order to populate your Model classes, however, more typically you will see Entity Framework and LINQ queries used in order to populate these Model classes.
In your Controller methods, you can either return a View directly (no Model binding) or you can return a View and pass the entire model object back to the View (Model binding). In addition, you can do something that was typically difficult using traditional ASP.NET Web Forms technology--you can pass an entire object back from a View (typically done in the [HttpPut] Controller method).
So how do you return a View in a Controller method?
Very simply--either return View(); or return View(model);
Also, in your Controller methods, you can right click on a Controller method and create a View using the Visual Studio.NET IDE. You can create MVC views that are Empty or you can use the Scaffolding features in ASP.NET MVC to allow Views to be created with most of the functionality that you need such as Display, Create, Edit and Delete functionality.
Scaffolding is the process of binding your View to a particular Model. This can either be an Entity Framework class or it can also be a ViewModel that you have created. The Scaffolding framework will then generate all of the necessary code in your ASP.NET MVC View to perform all of the various actions that are needed to provide the functionality you selected when creating the View. Scaffolding makes the generation of rich functionality in your ASP.NET MVC web application very quick and easy.
You may be familiar with the concept of Scaffolding in ASP.NET Web Forms through the use of Web Server Controls and data source controls such as the SqlDataSource control which provided automatic add, update and delete functionality through configuration of the SqlDataSource control along with the Web Server control (such as the GridView control).
That is all there really is to it! Of course, there are many intricate details regarding the use of ASP.NET MVC including things that I have not discussed such as Layout views (Master Pages) and Partial Views (User Controls), but hopefully the basic understanding should help put you well on your way to developing with ASP.NET MVC!
Happy coding!!
