DotNetCurry Logo

Questions Developers Ask When Moving From ASP.NET Web Forms to MVC

Posted by: Suprotim Agarwal , on 11/5/2013, in Category ASP.NET
Views: 84160
Abstract: Some common questions that arise when seasoned WebForms developers tread in ASP.NET MVC, for the first time. It’s not an ASP.NET MVC vs. WebForms article, but rather focuses on what’s different and how.

When WebForms developers move to ASP.NET MVC, it looks like a whole new world. Today we look at some of the first questions that come up in an attempt to look at MVC from the WebForms Developer’s eyes. You may also want to check out my upcoming book with Pravin Dabade titled The Absolutely Awesome .NET Interview Book which contains plenty of questions for .NET Developers and Architects out there.

Question 1: Where are the Page_Load and the code behind? This separation of concerns thing is a little confusing how does it work?

To answer the first question directly, there is no Page_Load ‘event’ in ASP.NET MVC. Fact is there are no ‘Page’ events in MVC at all.

The MVC Pattern promotes separation of Model (data and logic), View (the HTML Page in case of ASP.NET MVC) and Controller (the glue between the View and Model) . To quote from my previous article - The MVC Pattern and ASP.NET MVC - Back to Basics we can define Model, View and Controller as follows:

Models: Classes that represent the problem domain (the problem/requirement we are trying to solve/accomplish). These classes also have code and logic to serialize and de-serialize the data into dedicated data stores as well as do validation and domain-specific logic. In ASP.NET MVC, this is the place for ORM or Data Access frameworks to do their magic.

Views: Views are essentially templates (cshtml or vbhtml files) used to generate the final HTML at runtime. Though, we say HTML, we could potentially return other types of Views like PDFs etc.

Controller: The class that manages the relationship between View and the Model. It is also responsible for accepting requests from the User and deciding which View to serve up if any.

This is different from WebForms where was intrinsically tied to the Controller that is the Code Behind. This resulted in mixing up responsibility of the View, the Controller (code to generate the HTML encapsulated in Server Side Controls) and the Model, often leading to strongly coupled implementation that were hard to extend. That said, you could write well-designed WebForms apps but you also had the additional responsibility of maintaining the discipline of separating concerns.

This article is published from the DotNetCurry .NET Magazine – A Free High Quality Digital Magazine for .NET professionals published once every two months. Subscribe to this eMagazine for Free and get access to hundreds of free tutorials from experts

 

Question 2: What's the fuss about Stateless nature of the web? Where did the ViewState go in ASP.NET MVC and how does data from the Web Page go to the Server now?

In all discussions involving MVC and WebForms you will hear how the Web is meant to be stateless. What it actually means is HTTP (the protocol over which Internet or the Web works) is a stateless protocol and it works on Requests from Clients to Server and Responses from server back to Clients. Beyond a Request/Response cycle, the server doesn’t know/care about the state of the client.

WebForms is an abstraction that was built on top of this, but it was primarily designed as an easy path for Developers from the Visual Basic world to migrate to the web world. So it mimicked things like Controls, events and event handlers and State. This implied there was a hidden overhead to maintain and transfer client state to the server every time some action was performed on client and handled on the server.

For example, if you were handling a TextChanged event on the server, it meant that the entire Page with its contents had to be sent to the server along with the information about this server call because Text on a particular control had changed. ASP.NET WebForms would then interpret this information and call the ‘text changed’ event handler to execute whatever code you had written for it. When the server side event handler returned, ASP.NET has to send back the exact same HTML that it had received along with the delta of whatever changes you made in the event handler.

All this overhead of information to manage state before and after the event handler is called, was all kept hidden from the developer, but was an overhead all the same. ViewState was one of the mechanisms used to manage the overhead.

In MVC, we no longer have this overhead or the server side eventing model. The only server ‘events’ are the HTTP calls of GET, POST, PUT, DELETE etc. It’s all the HTTP protocol level.

The following diagram that I borrowed from an earlier article makes things clearer

mvc-pipeline

Looking at the Diagram left to right, top to bottom, the User is sitting at a browser and makes a request over HTTP that goes to the Web Server (hosting ASP.NET and ASP.NET MVC). Once the request reaches the server, it goes through the routing engine, to the controller, which interacts with the Model, invokes the view engine if required and returns a View. If the routing engine doesn’t find the URL that the user requested, it returns an error.

Instead of requesting a URL, if user was posting data from a HTML Form to the Server, then the browser (or custom AJAX) stuffs the form data into the Request body and packs it off to the server, which then does something called ModelBinding to create strongly typed Models of the data and send it to the Controller.

Each and every interaction between the User and the Web Application follows the same premise as above. No events, ViewState or any other overhead. This segues us into the next question.

 

Question 3: Where are my Rich Server side controls? Do I have to make-do with HTML Controls only? What’s this new Razor Syntax?

As WebForms developers, if you are already panicking about losing your favorite server controls, well, don’t panic, there are options for pretty much every server side control you have used. But to answer your question straight, there aren’t any ‘Server Side Controls’ so to speak in ASP.NET MVC. There are HtmlHelpers but their job is to make it easy to generate HTML on the server side, often using Model values etc. Since there is no ‘eventing’ per se, there are no ‘controls’. Whatever serverside parsing you do, end of the day, its plain old HTML that’s going to go to the user’s browser. Once on the browser, you can definitely use JavaScript frameworks and libraries to add richness to the interactivity.

Coming back to Razor Syntax, as we saw in the diagram earlier, the Controller after interacting with the Model may want to send back HTML Views. The templates for these Views are in respective cshtml files. View Engines interpret the cshtml in context of the Model and return plain HTML. There are multiple ViewEngines available in ASP.NET, each supporting a different server side templating language. The C# Razor engine looks for cshtml files that contain C# for templating, the VB.NET Razor engine looks for vbhtml files that contain VB.NET for templating. The ASPX engine is similar to the one used by WebForms and uses the <@ @> syntax for templating. Let’s look at an example of Razor Engine in action using C#.

Lets say we have the following controller

public class HomeController : Controller
{
[HttpGet]
public ActionResult Index()
{
  return View(new ScheduleTask());
}
[HttpPost]
public ActionResult Index(ScheduleTask task)
{
  return View();
}
}

The Index() method is called when you do a HttpGet and the Index(ScheduleTask) method is called when data is posted to the server from the browser.

Let’s look at the HttpGet method, first, we’ll look at the post while answering the next question.

As we can see the Index() method is calling the View(…) method and passing on a Model object to it. For sake of simplicity it’s just a new object without much data.

Things to note here:

1. The View method will return a ViewResult which will in turn have the HTML that needs to be returned to the Browser.

2. Since no name is passed to the View method, it will assume the name of the View to be “Index.cshtml”. This is the convention that ASP.NET MVC follows.

So what does the Index.cshtml look like?

@model DateRangeValidator.Models.ScheduleTask
@using (Html.BeginForm())
{
@Html.ValidationSummary(true)


  ScheduleTask
 

   @Html.LabelFor(model => model.Title)
 

 

   @Html.EditorFor(model => model.Title)
   @Html.ValidationMessageFor(model => model.Title)
 

 

   @Html.LabelFor(model => model.Description)
 

 

   @Html.EditorFor(model => model.Description)
   @Html.ValidationMessageFor(model => model.Description)
 

 

   @Html.LabelFor(model => model.StartDate)
 

 

   @Html.EditorFor(model => model.StartDate)
   @Html.ValidationMessageFor(model => model.StartDate)
 

 

   @Html.LabelFor(model => model.EndDate)
 

 

   @Html.EditorFor(model => model.EndDate)
   @Html.ValidationMessageFor(model => model.EndDate)
 

 


  
 



}

This is a quick peek as basic Razor Syntax

1. The first line declares the fact this view uses an instance of the ScheduleTask object.

2. The @using (Html.BeginForm()) section simply wraps the containing HTML with a element.

3. The @Html.Labelfor helper generates a

4. The @Html.EditorFor(…) adds an appropriate HTML element based on the Model Property that is passed in. For example a simple String property generates an elment.

5. Similarly @Html.ValidationMessageFor adds a tag that shows the validation messages applicable to the Element.

By now you should have got an idea of how Razor Syntax, cshtml files and view engines are co-related in the MVC stack.

 

Question 4: Can you expand on Model Binding? Earlier you said data is posted in HTML Body, how does the controller end up with strongly typed objects?

Before we explain Model binding, let’s visualize how data is actually getting sent. Let’s say we are at the Index view and we fill up the following data in the From

index-view-data

Next we enable Network monitoring in the Browser DeveloperTools (I am using IE11 here), put a break-point in the Controller’s Index (HttpPost) method and click on Index button. The Form will do a POST and stop at the breakpoint at the Server. If we dig into the details of the Schedule Task object passed into Controller method, we’ll see the data we updated above has been passed to the server

posted-data

Now if we let the request go through and get back to the Browser, we can see the Request headers

form-encoded-post

As we can see, our Form is getting posted as an application/x-www-form-urlencoded. Now if we go to the Request body tab, we see our data is Url Encoded.

form-encoded-request-data

So somewhere in the Request Pipeline after MVC accepted the Request and before it called the controller, MVC converted the urlencoded data into a ScheduleTask object and filled in the property values. This is ‘Model Binding’. MVC uses the content-type, the data in the ‘Request body’ and the input parameter type of the targeted Action method to create the Model instance and populate the values. Other accepted Content-Types out of the box are JSON and XML. In each case we need to populate the Request Body appropriately.

 

Question 5: Okay, but I already have a massive legacy WebForms codebase, can I use ASP.NET MVC for new parts of my Web Application and ease into MVC?

For brown-field expansion projects, it is logical to introduce ASP.NET MVC slowly into the system for self contained new features. So does that mean we can mix and match WebForms and MVC? We did a really elaborate article on this one earlier and we strongly suggest you refer to it for the details. The outline of the steps involved are as follows:

1. We should upgrade out WebForms project to .NET Framework 4.0 or 4.5, this adds first class routing support, which is essential to make this work.

2. Next we add all the MVC Framework components required, using Nuget package Manager.

3. Update the Web.settings to configure MVC components.

4. To add MVC Tooling support, we need to rejig the csproj file manually by adding a GUID to the element.

5. Add a BundleConfig class and initialize them in the App_Start.

6. Finally add a new Area to the project. An Area is a logical unit of the application that you can apply custom routes etc. to as if it were a new application. To this new Area add the Controllers, Views, styles etc. as required to implement your new functionality.

Conclusion

With that we wrap up this Q&A session for devs moving from Web Forms to ASP.NET MVC. If you have more questions feel free to shoot them our way and we’ll try to collate them do one more article on the same.

Was this article worth reading? Share it with fellow developers too. Thanks!
Share on Google+
Further Reading - Articles You May Like!
Author
Suprotim Agarwal, MCSD, MCAD, MCDBA, MCSE, is the founder of DotNetCurry, DNC Magazine for Developers, SQLServerCurry and DevCurry. He has also authored a couple of books 51 Recipes using jQuery with ASP.NET Controls and a new one recently at The Absolutely Awesome jQuery CookBook.

Suprotim has received the prestigious Microsoft MVP award for nine times in a row now. In a professional capacity, he is the CEO of A2Z Knowledge Visuals Pvt Ltd, a digital group that represents premium web sites and digital publications comprising of Professional web, windows, mobile and cloud developers, technical managers, and architects.

Get in touch with him on Twitter @suprotimagarwal, LinkedIn or befriend him on Facebook



Page copy protected against web site content infringement 	by Copyscape




Feedback - Leave us some adulation, criticism and everything in between!
Comment posted by Phillip on Tuesday, November 5, 2013 5:29 AM
Models: Classes that represent the problem domain (the problem/requirement we are trying to solve/accomplish). These classes also have code and logic to serialize and de-serialize the data into dedicated data stores as well as do validation and domain-specific logic. In ASP.NET MVC, this is the place for ORM or Data Access frameworks to do their magic.

^This is the biggest misconception of MVC. The Model doesn't represent the domain in any which way. Its's a composition of data available to the view. It should be called a ViewModel.
Comment posted by Phillip on Tuesday, November 5, 2013 5:55 AM
Models: Classes that represent the problem domain (the problem/requirement we are trying to solve/accomplish). These classes also have code and logic to serialize and de-serialize the data into dedicated data stores as well as do validation and domain-specific logic. In ASP.NET MVC, this is the place for ORM or Data Access frameworks to do their magic.

^This is the biggest misconception of MVC. The Model doesn't represent the domain in any which way. Its's a composition of data available to the view. It should be called a ViewModel.
Comment posted by Suprotim Agarwal on Tuesday, November 5, 2013 6:17 AM
Phillip: Models can both "contain" as well as "represent" data. It can be called "viewmodel" if you are "representing" data transferred between views and controller. It can be "domainmodel" which "contains" the data in a business domain.
Comment posted by Sylvain Chamberland on Wednesday, November 6, 2013 8:44 PM
But that's not what the model in the MVC pattern - or in any MVC framework - is supposed to be. For a good explanation of where some current MVC frameworks go wrong, and of what the MVC pattern is supposed to be, check the recording of Robert C. Martin's conference at NDC 2013 on Vimeo. The part about MVC starts at 31:34.
http://vimeo.com/68215570
Comment posted by vagat singh on Wednesday, March 12, 2014 1:49 AM
very nice
Comment posted by Ankita Priya on Friday, July 25, 2014 6:29 AM
I want to display a details view without data.
0nly columns will show not data will be shown.
guys any Idea.

Comment posted by pg on Sunday, May 24, 2015 8:21 PM
i want to develop web based database application in ASP.NET 5 using MVC architecture.
Can you suggest how i should proceed
Comment posted by Suprotim Agarwal on Monday, May 25, 2015 6:42 AM
@pg: Here you go: http://www.dotnetcurry.com/showarticle.aspx?ID=1061