How to structure, partition, and build large MVC application for deployment in small incremental pieces?

Question

We will be developing a very large vertical market web application, and are leaning toward the MVC approach.

It will have 1 Master Page common to all views in the application. The master will provide a navigation/search framework for the entire application that will allow users to search and select entities and then navigate to a function to perform.

The database model will have 700 to 1000 tables. The application will have hundreds of controllers.

Controllers and their views could be grouped together into one of the many (20-50) subsystems in the application. (We are looking at an areas approach to aide in organization).

We want to be able to deliver enhancements/updates in small functional pieces. These might me a new function, a bug fix, customer dependent functionality, or optional modules separately purchased by the enduser.

We spent too many years developing/supporting and delivering one large windows vb app exe. We would like to take another approach.

Management does not want to deliver one large application. They want to be able to deliver small incremental pieces when necessary.

We may want to create a deliverable that contains one controller, and only a couple views, and a portion of the model.

To deliver it, we want to copy a dll to a bin folder, and create a View folder and copy in the new view(s). As simple as possible!

I have spent many days researching this and haven't come up with a clear path to proceed. (Every tutorial and article I found assumed a single project.)

How do we structure the application to accomplish this?

How do we break up the application into separate projects/assemblies to do this?

Can you build a base project that contains the Master Page, authentication, and Global routing, and then reference this in each of the potentially hundreds of other projects for each of the modules?

In development, does each sub-project need to contain the entire base project, or just the shared views folder, Global routing, and web.config and a reference to the base project dll?

Any detail documents explaining this approach?

Any development/Testing issues?

Thanks for all input, we have to get this going soon.

Update:

Followed the example here link text

It is a great starting point!

Answer 1

I think this is exactly the case where DLR would help. Your Controllers and Views can be stored as scripts in the database. It will be very easy to deliver your application as a set of "small functional pieces". You could start from reading Haacked - Scripting ASP.NET MVC Views Stored In The Database

Answer 2

Google for MVC with MEF. There is an example by one of the MEF team that will suit your needs exactly.

Answer 3

Absolutely, break the project up into sub-projects / modules containing your controllers. You can use an IoC container like Unity, Spring.Net, or Castle Windsor to locate your appropriate controllers in the child projects.

Implement your own IControllerFactory to do the Controller lookups in the IoC container based on the controller name passed to it. You're looking to put in place an IControllerFactory.CreateController method that looks something like:

public IController CreateController(RequestContext requestContext, string controllerName) 
{
  return (IController)IoCContainer.GetObjectByName(controllerName);
}

Then you should be able to simply modify your IoC configuration file to define your new controllers as they are deployed.