5 Factors to Consider When Converting a WebForms App to ASP.NET MVC Core

May 11th, 2016

For those interested in moving their legacy WebForms application to ASP.NET MVC, today, I provide a list of factors to consider before starting your conversion.

Let's play the word association game.

What's the first thing you think of when I say "Legacy application?" (Immediately, post your first thought in the comments below).

As developers, we all cringe when we hear that term. Since we have the improvements, schedule, and roadmap for .NET Core, I'm sure a lot of developers are evaluating what it takes to upgrade their existing applications to Core.

But how much work will it take? This is a whole new world with .NET Core. How old is the code in that legacy application?

Is there a clear upgrade path? Is it spaghetti code? Will it break if I refactor the code? Are there even unit tests to confirm the code works? Is it a web site or a web application?

Finally, we all asks ourselves under our breath, "what did we get ourselves into with this project?"

If you are in this situation, or have been in the past, then these factors may look familiar to you.

If you are upgrading a WebForms application to a .NET Core app, strap yourself in, this may get bumpy.

1. User Controls/Web Controls

This may be the most disruptive problem in your Web Forms application.

Why?

These types of controls may have been built with business rules included in them.

Not only that, but your WebForms could have third-party UI controls inside of them (think Telerik or Infragistics).

This would make your conversion process to .NET Core a huge problem to .NET Core since User Controls/Web Controls aren't available anymore.

Now, it's a JavaScript world! You need to either find or write JavaScript controls;-)

Possible Next Steps:

  1. Take a consensus of all User and Web Controls in the project and determine if they are third-party.
  2. Divide the controls into two camps: build or buy (isn't that the ultimate question?)
  3. For the buy pile: Upgrade the controls or look for other vendors who transitioned their code into .NET Core already. If they aren't there yet, you may need to place the control in the build pile.
  4. For the build pile: Create MVC Partial Views, HtmlHelpers, or the new .NET Core TagHelpers. 

2. One Form To Rule Them All

With WebForms technology, a single form encompasses the entire HTML on a page. If you are moving to .NET Core 1.0 (or even MVC for that matter), you will need to restructure your forms on each WebForms page.

You can now have multiple forms on a single page and each form can "postback" to a different controller and action. This is a good thing. 

But it's definitely a mind-shift for people who were brought up the WebForms way or writing web applications.

Possible Next Steps:

  1. Scan through your WebForms and look for hidden form postbacks. The signature is an <asp:Panel...DefaultButton="blahButton">. These were workarounds for containing multiple forms "embedded" into one form.
  2. Separate them out into their own <form> tags in MVC.

3. IsPostback

IsPostback is a property on the Page object determining if a user clicked a button to submit a form. 

In ASP.NET MVC and Core 1.0, there isn't any IsPostback. The postback occurs when a user submits their form and you direct it to post to a controller and action.

Yet, with everything in WebForms, you define a button-click and execute the code.

This simple line

if (IsPostback) return;

provides a large benefit to developers because if a user pushes the button, then this line in the Page_Load would be the first thing hit, kick out from this method, and execute the button's click method. Anything after this line would be initialization of the page's code.

Over the years, I've seen a lot of this type of code:

if (IsPostback)
{
 
    // Do a lot of stuff.
 
}
else
{
 
    // Initialize the page.
}

There are times when a developer would code a WebForms page and the user would complain about posting back and their data is gone.

Possible Next Steps:

  1. In the WebForm's code-behind page, try to refactor the Page_Load method to just include the IsPostback one-liner and just write initialization code.
  2. Take your initialization code and use this as your code to initially populate your ViewModel in your controller's GET action method. 

4. DOM Manipulation

Everyone loves jQuery, but combine that with WebForms and you have a recipe for disaster.

What do I mean?

If you are performing any kind of DOM manipulation on a WebForm page, it's hard to hit a moving target.

The id for a particular DOM element would be

#ctl00_content_txtName

If you have a jQuery event like this:

$("#ct100_content_txtName").on("click", doSomething());

and you convert your existing page to ASP.NET MVC or ASP.NET Core 1.0, your id's will now be txtName.

As it should. But your application will break.

I understand there is a ClientIdMode which will help, but lately, most developers don't keep up with the times and haven't included that particular attribute on any WebForms or doesn't know it existed while they were developing a WebForms page.

Possible Next Steps:

  1. Find as many DOM selectors as you can and convert them to use jQuery's "ends with" selector ( $("[name$=txtName]") ). This may get you some mileage for the time being.
  2. Try to convert and move in-line code ( <% txtName.ClientID %> ) to a JavaScript file for maximum portability to MVC or .NET Core.

5. Business Logic...IN THE UI!

When WebForms appeared in 2002, many developers wrote their business logic into the code-behind. Since they were already there working on the UI, why not just code it in there?

The problem with that is that you can't reuse the code anywhere else...only in the user interface (UI).

In addition, you may have some JavaScript validation in your WebForms which is considered business logic. This leads to the Reese's Cup Dilemma.

With MVC, you have a logical separation of concerns.

This is what made MVC so attractive. It disciplined developers to rethink the modeling of their data.

Possible Next Steps:

  1. Find as many JavaScript (and code-behind) validations as you can and move them as close to your C# business objects as you can. Transfer this logic to business methods and/or use validation attributes on your business models.
  2. Create returnable Data Packages (translation: ViewModels). Focus on the specific data required for a WebForm and return everything you need to your WebForm. This will translate extremely well over to an MVC model.

Conclusion

In this post, I mentioned five factors when you convert WebForm code over to an MVC model in either ASP.NET MVC 4/5 or to Core 1.0.

I hope this post has prepared most developers for moving their legacy application more towards an MVC model.

Did I miss anything else we could convert from legacy WebForm applications? Oh, and don't forget to post you thoughts when you hear the word "Legacy." Post your comments below.