We inherited a large ASP.NET website built entirely in WebForms. The website has over 200 pages, spread across 60 WebForms projects inside of the website's solution. About half of the pages are static content while the other half has a varied amount of server side complexity, mainly data capture and display. There is no use of ASP.NET web server controls as we've been phasing them out in favour of pure html. We handle SQL data via (a lot of) stored procedures on the SQL server. Our servers run Windows Server 2012 R2, IIS 7 with ASP.NET 4.5 framework.
We're researching if it's feasible to gradually convert to MVC or if a full MVC re-write is the best way to go.
To avoid becoming too broad, this question is about the general (non project-specific) procedure of converting a WebForms ecosystem into an ASP.NET-MVC ecosystem. And the specific focus is effort estimation (given the above project measurements).
Own research
The reasons why we want to convert WebForms to ASP.NET-MVC are mainly:
- routing and SEO friendly URLs,
- better structure and separation of code,
- the Entity Framework for central management of data,
- scaffolding for speedy development via auto generation of code,
- the Web API for AJAX communication and seamless update of page without refreshing, — and to move away from the no longer supported (since .NET 5) webforms platform.
We understand that some of these concepts can be plugged into webforms but not as well integrated as in MVC. We'd like to take advantage of the flexibility that MVC offers.
So, I suppose we're going to need to do something like the following:
- convert gradually:
- add an MVC skeleton structure that covers a specific part (likely the site .master and respective controls (.ascx) and a single WebForms project)
- fill in the structure with functionality, reusing relevant chunks of existing code by refactoring them as needed
full rewrite: - create a full MVC structure, possibly creating a new project structure, re-partitioning functionality between them
- fill it in by copy-pasting existing code or rewriting parts that are easier this way
These may be incorrect, of course; as I said, it's what we have for now.
Questions:
Could you outline a high-level conversion procedure in either case?
Specifically,
- in the gradual converting scenario, what's the most painless process?
- To re-write and replace the site .master and dependent controls to MVC layout and views and then load the remaining yet to be converted content into the new MVC layout?
- Or to load views into the existing master page?
- Or can you suggest and alternative method that will minimize duplicate MVC and webforms content during the transition period?
- in the full rewrite scenario, is it preferable to combine everything into a single MVC project, keep the existing 60 projects structure or repartition the functionality by an MVC-friendly principle? Currently the project structure matches the URL structure.
Any guidance or constructive feedback would be much appreciated.
Best Answer
For a site this large, I'm going to recommend a gradual transition.
Determine if you have a web site or a web application.
Asp.Net Web applications bring a lot of their own benefits, but the most important one for you is that they have a "mixed mode" and can run both Webforms and MVC from the same application. If you have a site, you'll need to migrate to an app. It's a simple and relatively safe process. Shouldn't take more than a day or two.
Identify the parts of your code that are painful to work with or change often.
These are your first targets. You'll get the biggest bang for your buck if you tackle these first. There's no sense in "fixing" code that never changes.
Invest in a refactoring tool like ReSharper.
I seriously could not imagine undertaking such a project without a tool that helps you quickly and, more importantly, safely clean up your code.
Introduce a new class library project to house your data access and common business logic.
The project is going to be in a state of flux for some time (perhaps forever). You're going to want to centralize logic & functionality that's common to your Forms and Controllers.
At this point, you may or may not want to introduce Entity Framework. The safest thing to do is to extract your data access into this library, introduce an interface to it and replace the ADO.Net data later with a shiny new EF one later.
Have a plan.
A project that this will quickly become a quagmire if you don't have realistic, obtainable milestones.
Lastly, consider whether you really need to move to MVC to clean this up, or if it would be sufficient to learn the Model-View-Presenter pattern and refactor your existing code into it. It's a flavor of MVC (the pattern, not the framework) that works very well with Webforms. Properly applied, it will give you many of the architectural benefits that MVC will give you.