Где должны жить мои модели? Веб-уровень или уровень данных? (MVC + NHibernate)

Я создаю n-уровневое приложение с MVC, Ninject и NHibernate (мой первый опыт использования этих технологий). Для ясности ярусы представляют собой уровень "данных", уровень "Услуги" и "веб-уровень" (все это отдельные проекты).

С MVC у вас есть ваши модели, находящиеся в папке "Модели". Кажется необходимым поместить мои модели здесь для создания сильно типизированных представлений и, как правило, придерживаться философии MVC.

Однако, с NHibernate, мне также нужны мои модели в уровне "Данные", так что это может произойти, и что NHibernate может создавать фактические объекты для возврата на уровень сервиса.

Дублирование классов по проектам не очень DRY, и абстрагирование их в свою библиотеку, похоже, не очень хорошо работает с MVC (ни на практике, ни на философии).

Любые мысли? Как вы структурируете свои объекты O/RM против моделей MVC?

Ответ 1

Я сохраняю модели/классы Entity Framework в уровне данных и использую папку Models в проекте MVC для моделей презентаций и привязок к образцам.

Ответ 2

Модель данных - это собственная вещь. Модель в MVC - это нечто другое. Это модель того, что вы собираетесь отображать, что может быть или не быть вашей моделью данных. Модель данных может превосходить слои, или нет.
Возьмем, к примеру, стандартную регистрационную форму. Модель данных может включать имя пользователя, пароль и массив классов истории входа, флаг, указывающий на его активность и многое другое. Модель в MVC может действительно заботиться только о имени пользователя и пароле, а также о том, что пользователь вводит пароль дважды. Требуется ли вашей модели данных два поля пароля? Нет. Однако модель в MVC. Следовательно, два разных твари.

Ответ 3

Я сохраняю все свои модели в уровне данных из-за NHibernate. Взгляните на S # arp Architecture за отличный способ сохранить вашу презентацию чистой. Модели не обязательно должны быть физически расположены в вашем веб-проекте, чтобы ваши представления были строго типизированы.

Ответ 4

Вы правы в принципе DRY здесь. Я сохраняю свои объекты LINQ-to-SQL отдельно от своих бизнес-объектов, и у меня есть некоторое дублирование, и это не заставляет меня чувствовать себя хорошо, но кажется, что нет простого обходного пути.

У меня было трудное время, чтобы принять это решение, но я смотрел блог Роба Конри, создавая MVC Storefront, и в конце концов я решил пойти этим путем (объекты ORM и бизнес-объекты)

Ответ 5

С MVC у вас есть свои модели, которые находятся в папке "Модели". Кажется необходимо поставить мои модели здесь создавать сильно типизированные виды и как правило, придерживаются философии MVC.

Никакая модель не может быть чем угодно. Я бы по-прежнему использовал модель представления, если это было необходимо, но у меня нет возражений против использования ваших nhibernate-объектов в ваших представлениях.

В NHibernate вам действительно не нужен уровень данных, поскольку сам сеанс является уровнем данных.

Уровень обслуживания кажется правильной идеей, но только если вы планируете иметь несколько клиентов для этого уровня.

В противном случае у меня будет только 1 проект и использование пространств имен для разделения моих слоев. Он работает быстрее и легче развертывается.