Встречалось мнение, что количество сборок, входящих в состав solution'a напрямую влияет на скорость билда. Также утверждалось, что один проект из 1000 файлов скомпилируется гораздо быстрее, чем 10 проектов из 100 файлов каждый. Кроме того, у автора этой точки зрения возникали серьезные сложности с реорганизацией структуры солюшена, состоящего из относительно большого количества проектов. Вследствие чего приводился довольно радикальный подход к организации ASP.NET MVC проекта. Выделялось всего 2 сборки:
- UI контент, соответствующий структуре при развертывании (views, CSS, images, Global.asax, Web.config)
- Весь остальной код (абсолютно весь (!) код, включая контроллеры, модели, модели вида, репозитории доступа к данным, определения для ORM мэппинга и т.д.)
Отсюда вопрос — как наиболее рационально подходить к разбиению solution'а на проекты?
Ну это понятно, что руководствоваться нужно логической структурой. Вопрос как раз в том, какую структуру выбрать. Вот видите, в приведенном примере весь код помещен в одну сборку. Хотя можно было бы выделить отдельную сборку, например, для объектов домена.
Если у вас один сервер, на котором работает этот проект, и в качестве клиента используется только браузер, то можно оставить все как есть. Смысл разделения приложения на отдельные модули скорее в том, что бы можно было эти модули использовать в других приложениях. Т.е. если в вашем проекте есть какой-то кусок логики, который без изменений можно использовать где-то еще, то тогда имеет смысл выделить этот кусок в отдельный проект.