ASP.NET MVC организация решений

Question

Я хочу создать довольно крупномасштабный проект ASP.NET MVC и хочу разбить его так, чтобы он не был все в одном проекте и одной сборке.

Я посмотрел, как Oxite делает свою организацию (http://oxite.codeplex.com/Wiki/View.aspx?title=architecture), но мне было интересно, как другие люди делают это тоже. Есть предложения?

В настоящее время я рассматриваю что-то очень похожее на Oxite:

Проект - Этот проект содержит уровень модели, который включает модели, классы конфигурации и интерфейсы для служб и репозиториев. Здесь не должно быть много логики приложения, в основном структуры данных.

Project.Core - Этот проект содержит весь код для контроллера и маршрутизации, включая фильтры и результаты. Также сюда включена модель ViewData.

Project.Site - Этот проект содержит виды, изображения, javascript и все другие статические файлы без кода. Здесь должен быть минимальный код C #, большинство должно жить в Project.Core

Answer 1

Возможно, вы захотите проверить, как S # arp Architecture разделяет свои контроллеры, сервисы и ядро ​​на проекты с соответствующими тестовыми проектами.

Answer 2

Вот как мы разбили проект. Этот ASP.NET MVC довольно близок к запуску, и мы узнали несколько вещей на этом пути. Я привел причины, по которым каждый проект также является отдельным.

Project.Models - M в MVC, содержит все ваши бизнес-классы. Если вы можете управлять им (и вам действительно следует), здесь не должно быть классов, связанных с постоянством или веб-сервисами. Конечно, вы можете иметь интерфейсы для доступа к данным, определенные в этом проекте. Быстрый способ проверить, является ли этот проект «чистым» от доступа к данным, - это проверить, нужны ли в этом проекте ссылки на DLL-библиотеки доступа к данным, такие как NHibernate, или нет. Причина: теоретически вы должны иметь возможность связывать этот проект и использовать эти классы где-либо еще, даже если вы переключаетесь на другой пользовательский интерфейс, например консоль и т. Д.

Project.Site - Этот проект содержит все ваши JavaScript, CSS, View и т. Д., Все, что связано с View. Причина: если у вас есть дизайнер веб-сайтов, вы можете просто предоставить ему / ей доступ к этому проекту и заставить его поработать.

Project.Controllers - C в MVC, содержит все ваши контроллеры, а также ваши ModelBinder. Причина: три разных проекта для Моделей, Представлений и Контроллеров затрудняют возникновение проблем.

Project.Tests - Хранение всех ваших модульных тестов в отдельных проектах вынуждает вас тестировать только общедоступные интерфейсы; на мой взгляд, хорошая практика для юнит-тестов.

Projects.Services - Все веб-службы, код, связанный с постоянством, находятся здесь в этом проекте.

Пока что все классы Utility входят в Project.Models, но я думаю, что было бы намного лучше иметь отдельное решение для классов Utility и просто импортировать их как ссылки на скомпилированные сборки, где это необходимо.