Running multiple sites from one ASP.NET code base and moving to ASP.NET MVC

Question

I have a reasonably large project at work that I've inherited. It's an ASP.NET 2005 website project and two C# library projects for data access and some business logic. The code actually runs 6 different database driven websites. It displays different images and text for each site based on logic that examines the URL and uses a series of Web.config values and switch statements.

We now have several new websites that will follow the same pattern and framework as these 6 and so management has decided that we should not reinvent the wheel and we should continue to extend the existing code. While I understand the decision from their perspective, the thought of extending this code with even more Web.config values and even more switch statements throughout feels wrong. It seems like there should be a better way to manage this particular form of complexity, but I don't have a handle on what that better way should be.

At the same time, I've been looking for a project to start learning ASP.NET MVC and I've been leaning towards re-developing this project with it on my own time since it's complex, but the requirements are in the code. I'm looking to gain 3 things out of moving it to MVC: 1) be able to test the app and all it's versions and all it's dark corners that I don't even know exist yet, 2) hopefully find a way to make managing about 12 sites on a single code base manageable and 3) learn MVC.

After rambling a bit, here are some specific questions:

Will MVC actually offer me better ways to manage the 12 site in 1 code base issue? It's a bit hard for me to tell without having a deeper knowledge of MVC.

Is there a templating pattern or framework that I can apply (in either WebForms or MVC) that is suited for sites like these that have similar content and structure and run from the same code base?

Is there a better way than examining the URL to decide which site is being viewed and what the images and text should be displayed for each site?

Thanks for the time. I do appreciate it!

Answer 1

ASP.Net MVC might have some real advantages for you here. You wouldn't be manually examining URL's any more, because the Routing functionality of MVC would do it for you - so in a way, it is a "better way". Here are some advantages:

1. URL routing is an easy way to differentiate which site was being served, and your "which site am I" parameters would be automatically handed down to every Controller (and subsequently, every View) if you structured your routes correctly.

2. URL Routing works both ways, so it would be relatively straightforward for you to define a single View for all your sites that generated proper images and script references to whichever site directory you needed.

3. Partial Views would be a great way to switch in site-specific content in corner cases where the template wasn't exactly the same for each site.

As long as the logic was reasonably similar for each site, ASP.Net MVC 1.0 could handle this. If you need different controller logic for each site, the upcoming release of ASP.Net MVC has the concept of "areas", which would allow you to implement different sites in the same application that all had their own Controller, Model and View directories - but were differentiated by their routes.

Answer 2

Will MVC actually offer me better ways to manage the 12 site in 1 code base issue?

Honestly: I would not go this road. ASP.NET is powerfull enough to have a multitennant system. There are things that help to build multitennant applications in ASP.NET MVC. You have IoC for changing business rules between applications and you have the option to dynamically choose which view to render. You have testabillity.

Thats all great: read here about it link so

But still: It is an enourmous effort to implement such a system. ASP.NET is great (you got Routing now!) and if you have a running system better invest your time in making it better.