Migrating to ASP.NET MVC
January 18th, 2010A few months ago, maybe around November time last year when ASP.NET MVC 2 was being previewed, I was looking for excuses to build something to take advantage of as many new features as possible. Building a test site gets very dull very quickly, it just ain’t the same as a real project with real world problems. So I took the current site I was working on and decided to implement a small part of it in MVC. I figured it might be interesting, and had this crazy idea that I could one day convince everyone we should move the whole site.
The benefits of such a migration to a developer are clear, but I’m not naive. The site in question is our flagship e-commerce site built on tried-and-proven classic ASP (VBScript) technology, with huge amounts of legacy code, multiple franchise systems, admin systems, and large numbers of paying customers. If it ain’t broke, there’s no chance we’ll be spending months on a risky rewrite. So I knew I had to be cunning.
My goal was simple. If I could get a small part of the front-end site to run under MVC, and show significant benefit to our client, it might just happen. The bait? Performance. One of the big benefits of moving from a scripting language to a modern framework is the tools available for various levels of caching. The other main drive was to move from using several 3rd party tools (such as Java and ISAPI ReWrite) to a common language and framework (C#.NET). This would make site maintenance less of a headache for everyone.
Over the course of a few lunchtimes, evenings and Saturday mornings I threw together a test site. A few demos and a series comparison stats later and we had a proposal.
Over the course of a series of blog posts, I’ll be outlining the various challenges associated with this project and how we tackle them. This will include advanced and customised routing, caching, best practices and running new code side-by-side with legacy code. Enjoy.