MVC and old ASP.NET Webforms

G

guest2013-1

guest
Joined
Aug 22, 2003
Messages
19,800
Reaction score
13
We currently have an intranet web app that's in .NET 2.0 ASP.NET WebForms. We're moving into MVC 5 now and my boss wants us, instead of starting with a clean slate and embrace MVC fully, mix the old WebForms into the new MVC solution while we migrate all the modules to MVC.

In my opinion, it's more trouble than it would be worth just pushing through and migrating to MVC in one go (and doing a major code cleanup while we're at it)

What's your opinion? I reckon using IIS to link to the new module in the MVC app from the WebForms app as we complete a module would be better than having to struggle getting the old Webforms to work in the new tech.

Need the opinion of some MVC guys. We have about 5 modules excluding the admin of the site that we need to migrate. What would the time frame be for, just doing it in MVC vs trying to make .NET 2.0 Webforms work in an MVC project to start to migrate it.
 
It all depends on your experience with MVC. I find that once you know the ins and outs of MVC the development goes a lot quicker than on WebForms.

That being said though, I do agree with you, although my concerns would be much more to the side of you're going to end up with a lot unnecessary crap in your solution if your try to combine it.

Why do you need to go down either of those roads though, why not let users continue using the WebForms version until you're completely done with the MVC one, then roll that out?
 
Upgrade the webforms project to .net 4.5 first and test if it works. Then add all those asp pages and projects to a new solution with a MVC project.
You can run cshtml side by side with aspx in the same web project.
 
I have done many projects like this. I prefer to mix the technologies to get going.
Typically with a Web forms app you often find a lot code in the web form code behind (business logic, data access, etc..).
I start by migrating code into libraries and depending on the size of the project - use the onion architecture pattern.
New modules are built using MVC.

When time permits, the webforms stuff is migrated.

This enables you to also get rid of code rot as you build the libraries - and optimise/update existing code.

I am busy doing this with 2 projects right now.
One is webforms using Visual WebGUI and the other is classic ASP. The ASP one is a bit of a headache cause I had to first upgrade the site from MS Access to SQL Server. The site is in testing now and once live, the new modules the client requires will begin (MVC). The existing ASP stuff will remain for the time being and when I get gaps the ASP pages we be migrated.
 
I think the reason why he doesn't want to work on the MVC version and finish it, then roll it out, is because of the scale and the potential risk it poses when we switch over to the new version with potential bugs. This is our flagship software that the company uses nationwide, so we can't afford it being down for any reason, although I feel that by the time we do release, we'd have skilled up on MVC enough to fix the problem quite quickly and not sit with our current deployment issues (which is part of the whole reason why we're moving to the MVC framework to begin with)

Thanks for the input guys. I just need to finish some API work and get stuck into showing them how MVC in .NET allows you to rapidly develop without much coding.
 
Last edited:
There are many possibilities here. I personally do not feel that mixing webforms and mvc together is a good idea. However, with that being said, we had to do something like that on a small scale since we needed to use report viewer. So report viewer was running as an asp.net webform component while the processing logic was in mvc.

Still, I believe you guys would be able to create better code that is less error prone using a clean slate on mvc. Another point - where is all the data and business logic stored? If you're using entity, then you already have one layer to pull into mvc. Like for example, I did a demo app that uses entity for its data/business layer. Then, I had two seperate projects - asp.net mvc and asp.net webforms + WCF. The code was very similar since my DAL was taking care of the logic.

What about using an API layer if you want to support multiple clients? Abstract your logic into using something like ASP.Net Web API. This gives best of both worlds. You can have many types of clients then connecting to a ubiquitous platform. That would help future proof your app so that changes are easier to make and manage.

It really depends on your business and the depth of the project. You don't want to lose track of the project objectives, however, you don't want to "re-write" an application that uses legacy code and then makes it more difficult to maintain.
 
It looks like a lot of companies are moving over to MVC. I'm also currently working on rewriting a WebForms web app to MVC. MVC 4 unfortunately since we got to do it using .NET 4 so that it works on Server 2003.

However, we decided to do complete rewrite from the beginning. We aren't using any of the WebForms code. We are also using Razor now instead of ASPX. The best part? We are dropping legacy javascript and going with more lightweight options and going completely responsive.

For me the biggest advantage of dropping WebForms completely is that everything feels new and exciting. It's the pits to struggle with legacy code when you are working on something new. Eh, well that's my opinion.
 
I would never mix them either do it properly or not at all.
 
Been wanting to move into MVC for years now. Needs to have a side project when I have the time.
 
don't mix and match. id even go as far as having 2 sites in the interim if you really need to.

i have done 3 projects like this and have been an MVC dev since its beta. just don't mix and match it causes more technical debt than its worth.

also remember that ms used MVC as a way to introduce new methodologies like unit testing and TDD as well as new tech. half the gain and power of the MVC pattern is being able to leverage these methodologies.

don't do this project with the focus being on time to going live. you're not saving time you're trading devving from scratch time with time spent maintaining the code in the future.

you will gain nothing except the same bugs in a new system unless you take the opportunity to test your app thoroughly. it normally ends up in a completely new and better design once you code with testing in mind.
 
AcidRaZor said:
Thanks for the input guys. I just need to finish some API work and get stuck into showing them how MVC in .NET allows you to rapidly develop without much coding.
Click to expand...

er your last sentence bugs me a bit. scaffolding will only take you so far, most apps will need more than the standard scaffolded views and controllers
 
We're in the .NET 1.1 mindset back in 2002. So no entity unfortunately, there's a crap load of "business layers" though.

Not trying to scaffold, what I meant by that is it's easy to have, let's say, a required field with client and server side validation happen, than what we have now. Leveraging off of models will make our code consistent throughout the application, so when a developer forgets to put validation on a field on one page in our current setup, it's not a mission trying to figure out why we're getting users entering bull**** data and WHERE it's coming from.
 
AcidRaZor said:
We're in the .NET 1.1 mindset back in 2002. So no entity unfortunately, there's a crap load of "business layers" though.

Not trying to scaffold, what I meant by that is it's easy to have, let's say, a required field with client and server side validation happen, than what we have now. Leveraging off of models will make our code consistent throughout the application, so when a developer forgets to put validation on a field on one page in our current setup, it's not a mission trying to figure out why we're getting users entering bull**** data and WHERE it's coming from.
Click to expand...

Multiple business layers should be split into SOA objects. Query them via web api and then display on FE. Do not mix business logic within the MVC classes.
 
sp4ceman said:
one thing to think about is whether or not to go MVC or create an api that provides data for a presentation layer.

we had to recently add a mobile app and so we needed to pretty much refactor out a lot of our logic to provide for this new api
Click to expand...

semaphore said:
Multiple business layers should be split into SOA objects. Query them via web api and then display on FE. Do not mix business logic within the MVC classes.
Click to expand...

That's the plan and the reason why I want to move away entirely from what we currently have. Trying to relearn some stuff here across an entire team ;)
 
Well then i would not waste my time moving anything to MVC until those business layers have been abstracted.
 
I wish I could work along semaphore and have him mentor me. I wish I had your software development knowledge :(
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X