How can a large MVC 4 application be divided to multiple smaller applications?

Question

I have an "ASP.NET MVC 4 Web Application" divided in multiple areas in Visual Studio 2013.

The project grown large to the extent that I currently have a large number of areas in the application.

There one specific area that can be separated in another MVC 4 application by itself. I created a new MVC 4 application and moved this area to that application.

These are the problem I am facing:

1. The moved area uses code from other classes in the original app. Specifically, there is Shared area that contains some Attributes as well as a BaseController.
2. The views of the moved area also uses JS scripts and other content. Most of the time, the used scripts are not exclusive or specific to the area that uses them. So the content is cross referenced among many areas.

Here is what I tried:

1. To solve compilation errors, I tried to add reference from the old MVC app to the new MVC app so that the classes in the new app can see other classes in the old app such as classes in the shared area. However, this didn't seem to solve the problem.
2. To fix JS script and content issues, I created a solution folder and moved all the scripts to it. However, I can't verify whether that works or not since I can start the app due to compilation errors.

Here are my questions:

1. Does VS2013 provide some facility to separate MVC application or make an app refer to code and content from another app?
2. What do you think to be the best strategy to make such separation?

I tried searching SO and Google for how to accomplish such separation. However, what I found seems to be applicable to previous versions of MVC and VS. Since I am new the concept of MVC areas and MVC in general I can't get around this.

Answer 1

I would take a more general point of view on the problem. It's not specifically an ASP.NET MVC problem, but rather a .NET code organization issue. I don't believe there's any one specific canonical methodology, rather some general guidelines to help depending on your preferences and how your project/team works.

The overall items I would focus on is splitting up your code into separate assemblies and creating an asset pipeline.

Splitting assemblies allows your projects to compile and recompile independently, as needed. This has the added benefit if you need to split things across machines in web services and re-use in other related projects like WCF services, or if you need to do something like GAC specific assemblies depending on your requirements.

Putting things into a pipeline just makes sharing and managing everything easier.

Here are a few suggestions:

• You don't need 1 monolithic project in your solution for everything which it sounds like what you have. Divide things up into multiple projects, resulting in multiple assemblies. You can also have multiple solutions for independent pieces of the app that don't need other pieces to run.

• Start with any "back-end" and "business" logic that is shared throughout your application. For example if you have a CustomerService class that is used by multiple views, put it into something like MyCompany.MyApp.Services. Obviously, the more granular you get, the more specific your naming might get if you end up adding lots of projects.

• For MVC type projects specifically, it's usually very easy to split up your models into 1 or more assemblies. Example: MyCompany.MyApp.SomeGroupingName1.Models and MyCompany.MyApp.SomeGroupingName2.Models, or simply into 1 as MyCompany.MyApp.Models

• You can split your controllers into multiple assemblies as well, same as the previous point.

• You can abstract any kind of components in the UI into their own assemblies as well, same goes for views.

• Use solution folders as you mentioned.

• Introduce an asset management library if needed to help build out and solve the bundling of resources. If the library doesn't already do this, you can create an asset pipeline that this plugs into to do minification of css and js. Then in your app you simply reference the bundles you need in the pages you need, rather than always including everything manually per page or sharing everything in the whole site in the whole app.

• Prefer composition over inheritance when possible. It's not clear from your post, but I have seen many issues with people trying to implement a one rules them all base class for every controller, view, etc. It might work, as they say, until it doesn't. Still a good idea to use base classes and inheritance, but don't tie multiple things that do different things to the same base implementation. At that point, an interface might be more what you want if you need to enforce a contract of some kind.

A final point: If you bundle things in your content pipeline, the client minimizes the amount of times they download your scripts if you do it right, and you can have the browser try to cache it for other pages. Better sometimes to push a big file down once than make many network connections every page to different files that don't get cached easily or things that are inlined in your views.