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

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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