ASP.NET MVC solution organization

Question

I'm looking to create a fairly large-scale ASP.NET MVC project and I want to break it out so that it's not all in one project and one assembly.

I looked at how Oxite does their organization (http://oxite.codeplex.com/Wiki/View.aspx?title=architecture) but I was wondering how other people do it too. Any suggestions?

Currently, I'm considering something very similiar to Oxite:

Project - This project contains the model layer which includes models, configuration classes, and interfaces for services and repositories. There should not be much application logic here, mostly data structures.

Project.Core - This project contains all the code for controller and routing including filters and results. Also included in here is ViewData model.

Project.Site - This project contains the Views, images, javascript and all other static non-code files. There should be minimal C# code here, the majority should live in Project.Core

Answer 1

You may want to check out how S#arp Architecture has their controllers, services and core split out into projects with corresponding Test projects.

Answer 2

Here's how we've broken up the project. This ASP.NET MVC is pretty close to being launched and we've learnt a few things along the way. I've given the reasons why each project is separate as well.

Project.Models - The M in MVC, this contains all your business classes. If you can manage it (an you really should), there should be no persistence or web service related classes here. You can of course have Interfaces for data access 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 in this project or not. Reason: Theoretically, you should be able to bundle this project and use these classes anywhere else, even if you switch to a different UI like a console etc.

Project.Site - This project contains all your JavaScript, CSS, View etc., everything related to the View. Reason: If you have a website designer, you can just give him/her access to this project and have him work away.

Project.Controllers - The C in MVC, this contains all your controllers as well as your ModelBinders. Reason: Three different projects for Models, Views and Controllers makes harder for leakage of concerns to occur.

Project.Tests - Keeping all your unit tests in separate projects forces you to test only public interfaces; a good practice for unit tests in my opinion.

Projects.Services - All web services, persistence related code go here in this project.

For now, any Utility classes go into Project.Models, but I think it would be much better to have a separate solution for Utility classes and just import them as references to compiled assemblies where needed.