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

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

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

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

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

Есть предположения? Как вы структурируете свои объекты O / RM по сравнению с моделями MVC?


design-patterns asp.net-mvc nhibernate n-tier-architecture
person Jeffrey Harrington    schedule 13.02.2009    source источник
comment
Мне любопытно, как прошедшие 2 года подтвердили (уточнили, усилили и т. Д.) Этот вопрос. MVC3 меняет уравнение? Я готовлюсь к созданию гибрида между устаревшим уровнем данных nH и EF для поддержки каркаса. Каковы группировки проектов VS при смешивании NH и EF сегодня? - Спасибо   -  person justSteve    schedule 12.02.2011
comment
Как насчет сейчас!? Почти 2 года с тех пор, как был задан вышеуказанный вопрос?   -  person Pouya Yousefi    schedule 06.11.2012

Ответы (5)


arrow_upward
6
arrow_downward

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

person Craig Stuntz    schedule 13.02.2009
comment
Хорошо. Таким образом, похоже, что консенсус состоит в том, чтобы оставить модели представления на уровне Web, а модели домена - на уровне данных. Итак, что мой уровень услуг должен вернуть на уровень веб-сайтов? Должен ли он знать о моделях презентации? Или он должен возвращать модели предметной области? - person Jeffrey Harrington; 13.02.2009
comment
Нет, я не думаю, что сервисы должны знать о моделях презентаций. В самом деле, вероятно, служба не сможет узнать обо всех необходимых моделях представления. Служба должна возвращать объекты передачи, которые могут быть типами сущностей. Веб-уровень может превратить это в модель представления. - person Craig Stuntz; 13.02.2009
comment
В этом есть смысл. Тем не менее, это сопоставление моделей предметной области с моделями представления не кажется очень СУХИМ, особенно когда две модели будут похожи. - person Jeffrey Harrington; 13.02.2009
comment
Они не такие. Учтите: PM оптимизирован для привязки данных и языка пользователя. Он живет сам по себе на вид / действие. DM оптимизирован для совместимости с остальной частью домена. LINQ легко их преобразует. - person Craig Stuntz; 13.02.2009
comment
Тем не менее, для случаев, когда они случаются совпадают, вы можете передать DM в представление. - person Craig Stuntz; 13.02.2009
comment
+1 Это отстой, но это правильный путь. В мире RoR у нас обычно есть одна-единственная модель (а не две), и все быстро становится беспорядочным. - person Dan Rosenstark; 15.09.2009

arrow_upward
6
arrow_downward

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

person Jim Barrows    schedule 13.02.2009
comment
Хорошо. Таким образом, похоже, что консенсус состоит в том, чтобы оставить модели представления на уровне Web, а модели домена - на уровне данных. Итак, что мой уровень услуг должен вернуть на уровень веб-сайтов? Должен ли он знать о моделях презентации? Или он должен возвращать модели предметной области? - person Jeffrey Harrington; 13.02.2009
comment
Уровень служб должен возвращать модель данных. Или спросите себя ... что произойдет, если у меня другой интерфейс для доступа к моим службам? Чем меньше ваш уровень обслуживания знает о внешнем интерфейсе, тем лучше вам будет в долгосрочной перспективе. - person Jim Barrows; 23.02.2009

arrow_upward
4
arrow_downward

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

person Chris Conway    schedule 13.02.2009

arrow_upward
1
arrow_downward

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

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

person Andrei Rînea    schedule 21.02.2009

arrow_upward
0
arrow_downward

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

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

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

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

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

person Simon Laroche    schedule 13.02.2009
comment
С NHibernate вам действительно не нужен уровень данных, поскольку сам сеанс является уровнем данных. Чтобы реализовать шаблон репозитория, я абстрагирую уровень данных. Таким образом, мои службы запрограммированы в соответствии с интерфейсом, а уровень данных легко взаимозаменяем (т. Е. Переключение O / RM). - person Jeffrey Harrington; 13.02.2009
comment
Затем вы можете поместить свои объекты в основную библиотеку и затем разместить свои репозитории с вашими сервисами. Репозитории - это сервисы. - person Simon Laroche; 14.02.2009