Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Can you refactor to MVC?

Not feeling too subtle today so I’ve given the punchline away in the title here. After wandering neck-deep into MVP and MVC, I’m now thinking about refactoring brownfield applications toward them. And it occurred to me: is it reasonable to refactor to MVC? Then, is it feasible? Then, is it even possible?

I’ve built started three or four MVC applications and love the framework for greenfield apps. But assuming you have a nice, healthy (and I’m using the definition "of great size") web application, would you go through the exercise of converting it to MVC?

Here are some reasons why I wouldn’t.

First and foremost, your URLs will change. Instead of http://myapp/ProductList.aspx, you have http://myapp/Products/List. Depending on the size of the app, I’m not sure I’d trust a global search and replace for that. Besides which, I’d rather be using one of the helper methods to generate the URLs in MVC.

Granted, you might be able to get around this with some combination of HttpHandler or HttpModule. Whether or not there is enough benefit to be gained from MVC to go through this exercise probably depends on the size of the app, your deadlines, and just how much blogging material you want to generate.

This segues into my next point. Unless you plan to refactor every page all at once, you need a way to have WebForms pages sitting along side MVC pages. Which means you need to be able to navigate directly to some .aspx pages in some cases, and to controller actions in others. This might be possible in the same project but it makes my head hurt thinking about it. You’ll be giving the routing engine a hernia with all the heavy lifting it would have to do. Either that or, again, implement your own HttpModule before the routing module in the pipeline.

Alternatively, you’d create a second web project, an MVC one, and move your UI over to it over the span of many moons. Your URLs will really get messed up as you’ll be essentially working in two separate web applications.

All of this presumes your logic is separated enough to withstand such a change. When talking about refactoring to layers in the brownfield book, we recommend doing so incrementally. That is, start by creating a seam and move all the code into it leaving a little bit behind in the UI. Then repeat for the big bulk of code you moved all the way down the line to the data access. (There, now you don’t have to read Chapter 8.)

Refactoring to MVC feels like this would be hard to do. Mind you, it shouldn’t really be any harder than refactoring to MVP. Maybe just feels that way because of the brownfieldedness of the apps I have swirling in my head. (Full disclosure: many of which I contributed to.)

Speaking of MVP, one of the main reasons I think this is too much work is because MVP is such a reasonable alternative. Maybe not 100% idea, but it’s a very viable compromise. On the one hand, yes, you still have to deal with the ViewState and the ASP.NET Pipeline and all the happiness that comes from trying to separate concerns in a real application as opposed to the contrived examples in books and blogs that make it look so easy. On the other hand, it’s less work to attain and in the end, you’ll end up with a more maintainable application.

So after all this windage about why I wouldn’t refactor to MVC…has anyone…y’know…tried it?

Kyle the Armchair Refactorer

This entry was posted in ASP.NET MVC, Brownfield. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.tavaresstudios.com Chris Tavares

    The thing is, MVP and MVC sit at different levels of abstraction. MVP is an implementation pattern on top of whatever you’re doing with your view. MVC, on the other hand, is an architecture that defines much more strictly what goes where.

    Architecture is, by definition, the stuff that’s hard to change. So I’m not surprised if refactoring to MVC is turning out to be difficult.

  • Kyle Baley

    Yeah, it may not have been obvious from the post but there is no reason to refactor to MVC (or any pattern) “just because”. And certainly if you are using MVP already, it would have to be a pretty crappy implementation to move away from it. I am referring to the case where you just have a mess of monolithic code and want to clean it up to something. MVP is probably the prudent choice.

  • http://www.kenegozi.com/blog Ken Egozi

    well I have experience in gradually moving live WebFroms applications into MonoRail world, and like any refactoring, if it’s doen carefully enough, in small incremental steps, you can keep the integrity of the system while moving.

    but you don’t do that for the sake of the change of course.
    if you have a great system, and the client is happy with, and the occasional change request is like “hey please change the word ‘foo’ to ‘bar’, or the bg from #010101 to #020202″, then the pragmatism calls for keeping it as is.
    however if it’s a live system with a lot of changes, both in logic and in ui, which calls for simplicity that is hard to achieve in WF, and with cool look’n’feel that no 3rd party server-control can implement without gazillion of hacks, then I’d say it’d be safer (and easier – even in the short run) to start the migration

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    MVP with WebForms (if you want to sully the good name of the MVP pattern) to MVC is a fullblown restructuring of the application. In no way can that possible construed as a “refactoring.” It’s a fullblown rewrite.

  • Kyle Baley

    Justice, I don’t know that being pragmatic == weakness. I too am a huge fan of MVC but I still don’t see the justification (justice-fication?) of migrating an entire application to it when it’s already built and (presumably) working. I suppose it would depend on the size of the app and the team involved.

    Sean, you bring up an awesome point that I completely forgot. MVC doesn’t do well with many server-side controls because of their reliance on viewstate. The idea of refactoring an application that relies heavily on a 3rd-party grid control…I can’t…the work…it’s too…the mind….brrrrr….

    Really, you wouldn’t so much refactor to MVC as you would rewrite the UI in it. Corey’s approach is probably the only reasonable way you could manage it, rewriting it a bit at a time whenever you get a request to change something in an area. It’s similar to how you would add unit tests to an app that previously didn’t have any.

  • http://graysmatter.codivation.com Justice~!

    WOW. I am very passionate about MVC, probably one of the biggest boosters of it out there despite its warts. However the pragmatist in me would be very worried about refactoring to what in some ways is almost a separate framework.

    I’m weak, I know…

  • http://weblogs.asp.net/sfeldman Sean Feldman

    IMO, refactoring to MVC will be not simple due to several key things that have some weight in decision making. First the dependency on 3rd party components. Those are designed with WebForms “caviar” built in. Second, it will make a “decent size” application non functional for a while, and I am not sure how many can afford that. Third – the mindset. Many will just refuse to change it, and I can understand that.
    What it seems is that many companies will evaluate MVC framework, and make their decisions. It will be interesting to see what will be the adoption rates.

  • Corey

    Personally, I feel that it is a very viable option. Although not suggesting the change for changes sake. Every significant change request we received from the business we decided to make that our marker to move the page(s) over to MVC. Luckily for us the business requests change frequently. It was never a problem to move a few pieces at a time to MVC while leaving the rest behind for the time being.