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

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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