This is a true story.

For starters, I’m not an MVC expert.

This isn’t a blog with all the answers someone transitioning to MVC is looking for.

I, like you, have searched the interwebs for such a publication, only to find that everything is pretty much task-oriented, focused on migrating a specific site or function to MVC. I found many blogs about why MVC is better, all the amazing benefits it brings to developers and marketers a like, and why Web Forms should(?) be buried deep in the ground, never to be seen again.

What I really wanted to find was someone who knew Web Forms and was starting to work with MVC. I wanted to know their process, challenges, and thoughts on the framework and how easily their skills related. So, I’m making an article from my point of view. A well-seasoned Web Forms developer who’s been thrust into the world of MVC. Sure, I’ve developed lots of sites using .NET. Over 19 years’ worth, actually. But that was using Web Forms, which is officially the newest inhabitant of the Island of Misfit toys. While I created many (self-proclaimed) awesome solutions with Microsoft’s legacy framework, MVC was never in the mix.

Until you’re the technical evangelist for a content management system that declares MVC as their primary focus. And then the fun begins.

[Learn more about Kentico’s new MVC support](https://www.kentico.com/product/mvc-transition-guide)

When I first started seriously looking at MVC over 2 years ago, I knew it was going to take some time to master. When so much of the platform goes against nearly 20 years of Web Forms thinking, I found it was sometimes tough to fully grasp core concepts. While MVC’s approach to routing, requests, and architecture aren’t completely foreign ideas, they still contradicted many of the techniques and designs I had built a career on.

Of course, there were a lot of similarities, which helped things a lot. Both frameworks have the concept of compartmentalized functionality and the same request/response capabilities. But under the hood, things are drastically different, and I’ve spent the better part of the past 24 months trying to make sense of it all.

Why has it taken so long? Well, when you’re a technical evangelist, you don’t really work on “real” projects anymore. Sure, I make a ton of POCs and enough demos to kill a donkey. But unless you work on a production-level, enterprise application, you never get the trial-by-fire experience for learning a new technology. Because of that, I’ve had to work at a different pace to get my MVC skills up to speed, using training, boilerplates, and a lot of trial-and-error.

Through all that, here are some of biggest takeaways thus far.

**DISCLAIMER**

No donkeys were harmed in the making of this article.

### **Architecture**

![](https://hackernoon.com/hn-images/1*d6HZLPABaaasFHv3d03ILg.jpeg)

Right from the start, the architectural differences between Web Forms and MVC are glaringly obvious. Long gone are code-behinds and designer files. Oh, and Web Forms page lifecycle? That’s outta here, too. Instead, there are Controllers, Views, Models, and helper classes for all your favorite code. The structure is clean, minimal, and easy to manage. Most of the sample sites set up this concept very well, and it’s pretty much the first thing every MVC training course will cover. Understanding the folder structure and naming conventions is key, and luckily this wasn’t too big of a challenge.

Over the years, I had tried to adopt good practices when it came to structuring and storing my code (for reusability), so the idea of specialized classes and folders for each MVC component was a natural concept. There were some parts that still confused me, like where’s the best place for interfaces and connectors, when to use partial/full views, and how in the heck you code the posting of a form. These were concepts that I was well versed in Web Forms, so transitioning them to MVC took a little while to get. But, with enough practice, anything is possible.

**Key takeaways**

*   MVC projects have a unique structure that allows the application to fulfill requests and match controllers to views automatically.
*   Having a proper project structure is key to having the site function properly, as well as portability of the code to other applications.
*   Microsoft has basically mandated that MVC is the future and the long-term support of Web Forms is not a guarantee. This means transitioning to MVC is an essential self-preservation move developers need to make if they like having jobs and money and food.

**Concepts to grasp**

*   View inheritance is a key concept. Understanding how and when to include the “master” layout will help you code your sites faster, and make one-off pages easier to develop.
*   By default, MVC sites are all about presentation. If you want to capture data, you often need to add in components to accept the responses, validate them, and process them correctly.
*   With MVC, developer tooling is geared to NuGet and package management. This means learning those systems is key to working with the framework as nearly everything will be brought in as a separate library.

### Understanding requests

![](https://hackernoon.com/hn-images/1*bLYySTSZRJvUXB21fWv8-Q.jpeg)

As I mentioned above, requests in MVC work significantly different than in Web Forms. While both MVC and Web Forms handle requests at the same stage of the life-cycle, getting the web server to interpret (and accept) the post is another challenge. Back in ye old days of Web Forms, you have the trusty Request object (technically, this is there in MVC, but the framework abstracts some of the details away for you). This canyon mule is capable of sending every bit of information about the user to and from the server. You can quickly pull out the values that you need and shove the rest of it into memory for a rainy day.

With MVC, things are much different. Because MVC is about modularity and light-weight applications, you have to build up every bit of the response from scratch. This means your controllers have to have the correct Action attributes so the application knows what to call, your models need to be updated to hold the entered data, and you need to ensure you properly validate all the responses. I found this to be a bit of a challenge in my learning, as I wasn’t used to having to create everything manually. After a lot of experimenting (and using some online form templates), I was able to grasp the concept and learn how to properly receive posted data into my MVC apps.

**Key takeaways**

*   With MVC, your forms will be created from the ground up. While this is more work, you can ensure your application is as light-weight as possible.
*   Everything in MVC is about making something happen in a controller. Ensuring your Actions and results are properly configured are essential to your application handling requests properly.

**Concepts to grasp**

*   When you first start with MVC, you generally have a pretty basic model. When it comes to forms, you’re going to have to update your models / view models with the appropriate properties to handle your data. This may go against your initial thinking of how data is handled, so be sure you understand exactly how it will function in your scenario.
*   Requests go hand-in-hand with routing, so make sure your routes are properly defined.

### Layout controls

![](https://hackernoon.com/hn-images/1*Jnh2-4fdd-3g9dljieE3rw.jpeg)

Because of the minimalist approach to things, MVC is all about complete control over the layout. Compare this to Web Forms “Let’s drag a control from the toolbox and have it wire everything up” functionality, and you’ll quickly see some pretty big differences. Where Web Forms is all about pre-wiring existing components, MVC is more about starting from nothing and only adding what you need.

Now, throughout all my WF development, I was never really a fan of the drag-and-drop controls, opting to build my own layouts from scratch. I did, however, always use server-side controls to build my designs, as this gave me access to the controls from the code-behind. This was pretty much the way every developer did it and it was a good model for web development for nearly 20 years.

While Web Forms provides the simplicity of design, it comes with a whole lot of overhead. All those server controls have ViewState, event handler capability, and auto-generated ids that run on for miles. While some controls like repeaters and grids gave the option to design on a per-item basis, the overall design was very elementary, and very limiting.

With MVC, the tables have been completely turned, and all the control lies with the developer and designers. Designers have full control over the layout, allowing them to use many of the built-in HTML Helpers to layout their page, or standard HTML input controls for even cleaner markup. Per-item layouts can be handled with Display templates easily, ensuring no pre-manufactured table layout will get injected into your otherwise flawless responsive site. This means only the essential elements are added to the View, without any of the 800-pound gorilla-Web Form baggage.

**Key takeaways**

*   MVC is aimed at simplicity. This means that developers are free to add only the elements and controls they need. This reduces the overall application and page size and drastically improves performance.
*   Layouts can be created with simple HTML elements, HTML Helpers, or a combination of both. This gives designers free-reign to implement their design without fighting the pre-generated output of the application.

**Concepts to grasp**

*   MVC is a minimalist approach to development. This means any design requirements have to be included manually by the developer. Things like supporting JavaScript, validators, and 3rd party libraries need to be included on the appropriate views if the layout depends on them.
*   Giving designers free roam over the presentation is a very powerful ability. You’ll need to work with them closely so that the application can implement their layouts correctly and still function properly.

### Helpful stuff

If you want to know the resources I used, here’s a list. There’s certainly a lot more stuff out there, but this should give you a good starting point.

*   [ASP.NET MVC Documentation](https://www.asp.net/mvc/overview)
*   [Microsoft ASP.NET Documentation](https://docs.microsoft.com/en-us/aspnet/#pivot=aspnet)
*   [Pluralsight ASP.NET MVC 5 Training Path](https://www.pluralsight.com/paths/mvc5)
*   [Microsoft NuGet documentation](https://docs.microsoft.com/en-us/nuget/)
*   [Kentico 12 MVC documentation](https://docs.kentico.com/k12/developing-websites/mvc-development-overview)

### Wrapping up

This article was about telling you the things I wish I knew before I started transitioning to MVC. There’s certainly more to the process than what I covered, however, these are some the important areas I had questions about. If you’re thinking about changing your skillset over to MVC, I recommend you start your studying now! Whether it’s online learning, books or peeking over the cubicle at the MVC-guru beside you, the main point is to get started. Time will most likely prove to be the best teacher as you work through your projects and gain more experience. It may seem like a big hill to climb but trust me, you can do it. In the end, it’s all web development and part of the developer gig.

Microsoft

Too Long; Didn't Read

Web Development & Ecommerce Writing Contest

2 Decades of Web Forms. Now, I’m Learning MVC.

Too Long; Didn't Read

Company Mentioned

@bryan_soltis

RELATED STORIES