Whenever a new technology or product comes onto the developer scene, people want to know how to best leverage their existing skills to work with it, and nobody wants to have to abandon existing knowledge. Making the move from Web Forms to MVC is no different. Despite the fact that Web Forms & MVC are very different ways of creating web applications on the ASP.NET platform, there are many skills and techniques to take with you.

Things you can leverage in both worlds.

The ASP.NET Core

The core is low hanging fruit when it comes to leveraging skills since you're already using it! It wouldn't make any sense for the ASP.NET team to create a completely new core framework just for MVC, or just for ASP.NET Web Pages, when using the current core works just fine. Things you're used to such as caching, membership, and globalization work the same across Web Forms and MVC, often with the only difference being minor syntax changes.

Digging deeper into a few examples demonstrates just how easy some of the core features are syntactically and conceptually.

Caching

Developers use caching just about everywhere, and caching is very easy to plug into MVC. Whereas you would normally use the @OutputCache directive in a Web Forms page, in MVC you need to move this code into the controller, as an attribute on an action method. Below is an example of output caching in MVC:

[OutputCache(Duration = 60, VaryByParam = "none")]
public ViewResult Index()
{    
    return View(bakery.Products);
}

Security

Like caching, security attributes decorate controller actions for authorization, for example, in the AccountController class, the Authorize attribute decorates the ChangePassword action method so it will only allow logged in users  to change their passwords.

[Authorize]

public ActionResult ChangePassword()

{

    ViewBag.PasswordLength = MembershipService.MinPasswordLength;

    return View();

}

Authorization can also work for specific roles in the application. In the below example, only those who are logged in either in the "WebAdmins" role or the "WebContentManagers" role can create new products.

[Authorize(Roles="WebAdmins,WebContentManagers")]

[HttpPost]

public ActionResult Create(Product product) {...}

Master Pages

All the rendering engines (page or view) behave in the same basic conceptual way - by rendering output based on controls or helpers, models, script, and HTML. On the other hand, their design time syntax and runtime outputs can be vastly different. This is seen right away while examining the default Master/Layout pages of each ASP.NET technology. Look at difference of the amount of code between a Web Forms Master Page, an MVC (Web Forms view engine) Master Page, and an MVC (Razor view engine) Layout Page.

Web Forms Master Page (traditional ASP.NET):

MVC w/Web Forms view engine Master Page:

MVC w/Razor view engine Layout Page (This surely is ASP.NET on a diet!):

Moving through the samples from Web Forms to MVC w/ASPX to MVC w/Razor, you'll see there's less, cleaner, code overall which leads to less, cleaner, code rendered in the browser. You'll notice an overall theme of less code in both regular Web Forms pages and views as well, not just in Master Pages & Layout Pages.

When talking about views, pages, or rendering, client side scripting has an important role, and is an easily transferrable skill set between platforms.

JavaScript & jQuery

JavaScript & jQuery are very portable, meaning that a single JavaScript script or .js file can be used anywhere with any web technology. If moving from Web Forms to MVC, you'll want to make sure the same HTML id, name, and class attributes match the rendered output by the views, as the ids, names and classes are the most affected parts of the output to the browser as far as client side script is concerned. jQuery lets you use less code to get the same result as with standard JavaScript, and in the world of software, less is more!

When using Web Forms, you tend to need utility-style JavaScript to deal with finding an element's id that the runtime generates, often looking something like this:

var obj=getElementById("MainContent1_GridView1_TextBox1");

Notice that the element in the getElementById is hard coded, which is the easiest, but not an elegant, way to select a DOM element using JavaScript. The code is also fragile, considering that at any time the element's attributes can change, and this code will break.

MVC solves this problem by using Unobtrusive jQuery and clean HTML. Since you maintain complete control over the output, there's no need for the same utility hooks normally added to Web Forms pages for things like validation. You can id or name an element anything you want in MVC, with no guessing as to what's generated at run time. Combine precisely rendered ids with jQuery selectors, and you'll find views to be very easy to code and maintain.

The previous JavaScript should look something similar to this in MVC:

var obj = $("#TextBox1");

If you're using JavaScript only and haven't looked into jQuery, I suggest you do. jQuery is a JavaScript framework built with JavaScript. Its purpose is to make working with cross browser DOM manipulation easy, and it does exactly that, wonderfully! Since jQuery is JavaScript, you can also easily mingle the two; again meaning that client side script is very portable skill. 

Visual Studio 2010

Although Visual Studio is an IDE and not a framework, it's a central part of ASP.NET development, regardless of the technology. You can use Visual Studio 2010 to create all available types of ASP.NET applications. Since Visual Studio is a full featured IDE, it has various dialogs/builders to help you quickly and accurately write code in MVC.

Additionally, an entire ecosystem of Helpers, widgets, frameworks, and extensions live as NuGet packages that you can access by using the "Add Library Package Reference" as shown here.

Deployment

Visual Studio 2010 also features a UI for configuring deployment settings that works the same way no matter which ASP.NET project template you use. VS deployment allows you to configure some of the following settings:

• A choice of what files, assets, libraries, etc...you want to deploy
• Configure target IIS server
• Deploy SQL db updates , with your choice of schema, data, or both
• Works with msdeploy.exe command line tool for administrators
• Works with the IIS InetMgr management console tool for administrators
• Integrates with MSBuild.

Things in Web Forms you can't take with you.

ASP.NET Web Forms is an abstraction between you, the developer, and HTTP. ASP.NET Web Forms does this by minimizing the need to tap directly into HTTP GET & POST data by using controls, ViewState, and events. MVC lifts the safety blanket to expose HTTP, but while still providing just a tiny level of abstraction with features like Model Binding (matching POST values to strongly typed objects in your model).

The Code Behind: There's no code behind in MVC, you render output in a much different way, via HTML & Html Helpers in the view. This happens because the controller fetches and passes the model to the view to render. Because MVC has a finer separation of concerns, neither the view nor the controller should perform any business logic - though you'll often see business logic scattered about in web forms code behind files.

ViewState, Events, & Controls: There are no controls in MVC views, which creates the cascading effect of no ViewState and no events, as all three are dependent on each other. MVC uses Model Binding to accomplish carrying data across requests, by working more closely to HTTP, and therefore less interruption of the stateless nature of the web, as it only works with the minimum amount of data required.

Summary

By now it should be clear that if it's in the ASP.NET core, it's available everywhere. While you can't use 100% of your Web Forms knowledge in ASP.NET MVC, you can still use a good amount of it. MVC simply exposes a different way to do things. Having said that, there's no loss of what Web Forms developer can do in MVC, or vice versa.

Some of the considerations when migrating a Web Form to an MVC view will depend on the view engine, controls, (whether built-in, your own custom, or 3rd party) and other factors. You may have to wait for component vendors or OSS projects to add Html Helpers to their suites, otherwise you'll need to rewrite what is often complex functionality yourself.

Resources:

ASP.NET Home page

ASP.NET Web Forms

ASP.NET MVC 3