About organisation of an asp mvc application

Question

I'm starting a new web application that will be made of multiple parts or modules. My client want to be able to redistribute the application with a subset of modules to some other clients. I read about Areas in mvc2 which seems to be what i'm looking at. I would also like to develop those modules in side projects and have the right one build according to clients specifications.

Can someone with more experience than me with mvc can confirm that this is possible with areas.

thanks mateo

Answer 1

You actually don't need areas for this. If you develop each module in a separate project within a solution they will each have their own assembly. This should work unless I'm misunderstanding your requirements.

To further clarify: areas are generally used to separate a very large application into sections that may each have a different development team. For example stack overflow might have the question + answer engine area, the roles and permissions area, login and authentication, and so on.

Answer 2

I think each module should be a separate project (a single assembly/DLL with its own responsibilities). You'd "connect" each module as a lego :D. Then to redistribute the app with a subset of modules you'd have a build script where you specify the modules that are in and out of the final product. Each version of the product would come in different shapes (as in the lego game) presenting different functionality subsets.

Just to mention, the concept of Areas in MVC is this:

To accommodate large projects, ASP.NET MVC lets you partition Web applications into smaller units that are referred to as areas. Areas provide a way to separate a large MVC Web application into smaller functional groupings. An area is effectively an MVC structure inside an application. An application could contain several MVC structures (areas).

For example, a single large e-commerce application might be divided into areas that represent the storefront, product reviews, user account administration, and the purchasing system. Each area represents a separate function of the overall application.