Лучшее место для размещения объектов домена в приложении ASP.NET MVC?

Question

Я только начинаю свой первый проект в ASP.NET MVC. По своему опыту работы с веб-формами у меня обычно был отдельный проект, посвященный слою моего домена. Здесь у меня будут объекты, специфичные для моего домена, а также файлы сопоставления NHibernate и некоторая бизнес-логика. Большинство примеров, которые я вижу в Интернете, помещают эти классы вместе с бизнес-логикой в ​​папку Models в приложении MVC, а затем обращаются к ней из контроллера. Исходя из моего опыта, это может затруднить перенос этой логики на другую платформу, если это будет необходимо. В частности, я думал о возможности перенести его в приложение веб-форм, если этого требует окружающая среда. Это может быть наивным вопросом, но лучше ли иметь данные Домена в своем собственном проекте или в папке Models?

Answer 1

Если вы планируете повторно использовать модель вне приложения MVC, отдельная библиотека классов по-прежнему является приемлемой настройкой. Я делаю это, но оставляю папку «Модели» и помещаю в нее модели для моих представлений.

Если вы поместите свой DAL в App_Code в проект Webforms, то я бы поместил его в Models в вашем проекте MVC. В противном случае продолжайте использовать отдельные проекты, как вы были.

Answer 2

Я использую аналогичный подход. Я тоже использую MVC, и мне нравится иметь модель домена POCOs в отдельном проекте. Для приложения, которое я сейчас создаю, у меня есть следующие проекты:

• Cms.Data
• Cms.Services
• Cms.Domain
• Cms.Web

Cms.Data - это проект доступа к данным, который выполняет перевод из модели LinqToSql или Entity Framework в модель POCOs в Cms.Domain и наоборот. Cms.Services - это сервисный проект с бизнес-логикой, которая переносит / отправляет POCO с / на уровень данных. Наконец, Cms.Web - это проект MVC, который использует сервисы от контроллеров и POCO в качестве модели.

Мне нравится принимать критиков:)

Answer 3

Я планирую свои решения аналогичным образом - объекты businessLogic, dataaccess, domain находятся в одном проекте. Представления (веб), веб-службы, формы Windows, WPF ..) все входят в свои собственные отдельные проекты.

Таким образом, код, специфичный для пользовательского интерфейса, не фильтруется на нижних уровнях приложения. В большинстве веб-проектов мне приходилось взламывать форму Windows, чтобы вводить новые данные в базу данных или управлять каким-либо типом приложения, которое не может быть реализовано в веб-среде.

Если я запекаю в HttpCaching на бизнес-уровне, я не смог бы переключаться между представлениями.