From Web Forms to MVC: Necessary Shifts in Strategy, Mindset & Language

When it comes to the Web Forms vs. MVC debate, the question isn’t “Which is Better?”…but “How to Switch?”

I have been studying and trying to transition to Model-View-Controller (MVC) for about six months and I have come across some fundamental thinking that must be changed and new things that must be learned in order to make the switch. I worked with Web Forms extensively in my previous position, and since joining AIS have made a commitment to myself to embrace the switch. I am still learning, but this is what I have found so far (your results may vary).

Server Controls are bad.

Yes, I realize these are the bread and butter of the Web Forms application, but just accept it now and your outlook will instantly improve. For several reasons (page weight, testability, performance, etc.) server controls are no longer at your disposal. Welcome to the world of Razor and JavaScript. State is also not such an easy luxury anymore, and although in most cases you didn’t need it anyway, you might have gotten used to it being so easily accessible. Whether you like it or not, it was wasting precious load time for your application.

Thankfully, Razor is not much of a stretch to learn.  In basic cases, you can just swap out <% %> with @{ } and it behaves the same. It is a mix of common HTML and inline scripting, with strongly typed access to your data model (removing the need for code behind data calls).

JavaScript is now your saving grace. Take comfort though: there are several plugins available and frameworks to consider that will help you put a shiny coat on your brand-new MVC application.

Learn JavaScript!

Maybe I am an exception, but JavaScript was an anomaly in my Web Forms applications. If you’re like me, you haven’t had to use JavaScript much with Web Forms. It was easier to drop an Ajax control on the page and treat it like a server control. While Ajax is still a part of MVC, it no longer looks like a server control. For most actions that occur without a page swap, JavaScript is up to the task. Good news though, you can use your strongly typed data model (the @ in Razor) to access your controller-delivered values right from the page.

Learn C# (If you’ve been using VB with web forms).

Unfortunately, I fall into the “started with VB” category. I am still learning C# and it’s not just VB with semi colons. In my defense, VB was not my choice, the work I had to do in the beginning determined my language. At my previous employer I actually suggested the switch but the idea was rejected out of fear that C# programmers were more expensive to replace. This tip does not take sides with the C# vs. argument, but simply if you are learning you are going to need lots of examples. In my experience, most of the examples are in C#. Learning C# saves many trips to developerFusion to convert to VB.

Code behind is a thing of the past. Controllers are the future.

You no longer have to program your database calls, conditional formatting, button click events, etc. on the back of each page. This process is more centralized using controllers. In Web Forms, you may potentially have three pages that use the same or similar data source. Which means if you have to add a column to your data source, you have to change it three times! This is one of the major advantages for controllers: Do it once and every page calling that controller gets the message. If you have been brave enough to dive into TDD along with your switch to MVC, you already know that this is a major plus.

Entity Framework is your friend.

When I programmed web forms I used a DAL layer that was written before I started and I honestly never looked at it much. It worked and I knew how to call its methods and that is all I cared about. I know that Entity Framework is available in Web Forms, but it is much more of a requirement in MVC.

My Web Forms applications never cared about my database keys and relationships. I never had to “explain” to the DAL why I wanted to call the query I wished to call (actually most of the time I just used sprocs), I just did it and it worked. Now, since I have been exploring database first (my background is in database design so this is where I like to start), I am constantly reminded that the framework already knows how my database works, and cares much more about my relationships and keys. Don’t think “SQL Query”; this no longer works as EF is too sophisticated for a simple select statement.  Take some time to get to know EF if you didn’t use it in Web Forms.

Most important: Be patient.

MVC is more of a “long-term” application choice, and for this same reason, it takes more thought and planning to get the hang of. I even tried to switch back to Web Forms a couple of times out of frustration, but quickly returned with more determination. It’s a work in progress, but there is hope.

About Terra Gilbert

Terra is a Software Engineer working for Applied Information Sciences. She began her career in the Accounting field and soon discovered that computers were far more interesting. From those first experiences managing JDEdwards EnterpriseOne and automating balancing spreadsheets bloomed a thirst for knowledge in databases and applications. Terra returned to school to study database design and information technology. She has been working in the industry for the last 4 years, learning as much as possible along the way.

  • Pingback: Struggles of Switching from WebForms to MVC « codeterra()

  • Kim Neville

    Great post!  I’ve been on the MVC journey, too, and I’m happy to have left web forms behind.

    • Terra Gilbert

       Thanks! Me too, it was hard at first, but now that I’m getting the hang of it I don’t want to look back.

  • Kasey Krehbiel

    Thanks for a great post. I completely agree. I fell in love with MVC a few years ago and I’ve never looked back.

    You can even take the Model architecture a step further. By putting it in a “Framework” project, totally separate from the MVC project, you can use that architecture in any other project, for example, if you’re going to create a mobile or WIndows app based on the same data. MVC became a lot more powerful to me than it already was when I realized that the @model directive at the top of a view doesn’t have to come from the Models folder (or even from the same project) and you can use the same data annotations, such as [Required, DisplayName(@”User Name”)] wherever you write the model.

    • Terra Gilbert

       Thanks Kasey! I have not thought of that before but it makes sense, good to know.

  • Pingback: Deploy a Website to Azure Using Team Foundation Service | Applied Information Sciences Blog()