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.
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:
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.
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.
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.
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.
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.
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.
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.