ASP.NET MVC Engineering great software with ASP.NET MVC

Working with ASP.NET MVC, I’ve come up with a solution structure that works well for most projects. I’ve also included a reasoning for my choices, instead of just telling you how I’ve arranged my projects within the solution.

One of the major design goals for MVC is a strict separation of concerns. Your solution structure should reflect this. By using multiple projects, one for each concern, we can make sure that it’s easy to identify when concerns are being mixed.

• Models – The M in MVC, this contains all your business domain classes. There should be persistance or web service related classes here. If your classes require database acecss, it should be through Interfaces defined in this project. A quick way to check if this project is “clean” of data access is to check if you require references to data access DLLs like NHibernate. If you do, you’re mixing in data access with your business domain models. Reason: You should be able to take this project and plug it into any other solution, for example if you want to use these domain classes with a different UI like a WinForms application.
• Controllers – The C in MVC, this contains all your controllers as well as your ModelBinders. Reason: Having three separate projects for Models, Views and Controllers makes the separation of concerns explicit and makes it harder for leakage of concerns.
• Site – The V in MVC, this project contains all your views and master pages. This also contains all the content needed for your Web UI, including your JavaScript, CSS, images etc.  Reason: This project holds all the views and resources (JavaScript, CSS, images etc.) that constitute the Web UI. Again, by having a separate project for the Views, the separation of concerns between the View, Models and Controllers becomes explicit.
• Tests – This project contains all your unit tests, functional tests, integration tests etc. Reason: Keeping all your unit tests in a separate project forces you to test only the public interfaces exposed by the rest of your projects; a good practice for unit tests in my opinion.
• Services - All persistence related code go into this project.