Архитектура NHibernate?

Question

Я планирую реализовать свой следующий проект (asp.net MVC), используя nhibernate в качестве ORM. Поскольку у меня нет опыта работы с nhibernate, мне интересно, как мне организовать зависимости между различными проектами. Я видел что-то подобное в качестве рекомендуемого подхода:

• Интерфейс пользователя зависит от модели, репозитория и NHibernate
• Хранилища зависят от модели и Nhibernate

    ----- UI-----------------------------
   |                |                    |
   |                |                    |
    Model  NHibernate

Проблема в том, что я не хочу, чтобы код пользовательского интерфейса напрямую взаимодействовал с nhibernate, поэтому я думаю о чем-то вроде этого:

• Интерфейс пользователя зависит от модели и фасада
• Фасад зависит от модели и Nhibernate

----- UI -------- | | | | модель

Фасад, фактически будет иметь репозитории, а также инкапсулирует объекты nhibernate.

Это звучит разумно? Есть ли какие-либо рекомендации по предпочтительной архитектуре?

Thanx

Answer 1

Это обычно то, что я делаю в своих приложениях:

• Foo.Core

  • содержит доменные объекты, бизнес-логику и т. Д.
  • нет ссылок на какие-либо связанные с инфраструктурой сборки, такие как веб-службы, ESB или доступ к данным
  • некоторые люди также размещают здесь интерфейсы репозитория, но это выбор дизайна. Это позволяет вам иметь доменные службы, которые взаимодействуют с репозиториями, по-прежнему отделенные от NHibernate

• Foo.Persistence

  • ссылки на NHibernate
  • Реализации репозитория
  • Единица работы HttpModule для ASP.NET (помогает контролировать жизненный цикл сеанса NHibernate в веб-приложении)

• Foo.Web

  • ссылка на Foo.Core и Foo.Persistence
  • Ссылка HttpModule для управления сессией NHibernate

Foo.Web никогда не взаимодействует с NHibernate напрямую ... он всегда через репозитории. С контейнером IoC вы можете просто запросить IRepository и не заботиться о реализации.

Answer 2

Вы заявили, что планируете использовать шаблон MVC. Это означает, что ваш пользовательский интерфейс не будет взаимодействовать с уровнем данных (в вашем случае, NHibernate). То, что будет взаимодействовать с уровнем данных, - это ваш бизнес-уровень, а ваш пользовательский интерфейс будет взаимодействовать с вашим бизнес-уровнем.

Я не знаком с ASP.NET, поэтому я не могу посоветовать вам предварительно созданную структуру для этого, но в Java, которой я в основном пользуюсь, ваши EJB-компоненты изолируют ваш интерфейс от уровень данных, совершая все такие вызовы через EJB.

Подумайте об изоляции кода для каждого уровня. У вас есть ящик для каждого уровня, и каждый ящик может общаться только с ящиком под ним через определенные каналы. Таким образом, ваш уровень данных связывается с вашей базой данных, ваш бизнес-уровень связывается с вашим уровнем данных, а ваш пользовательский интерфейс взаимодействует с вашим бизнес-уровнем. Все эти коммуникации являются односторонними (то есть ваш уровень данных не знает о бизнес-уровне и т. Д.). Это означает, что если вы хотите заменить какой-либо уровень на новую реализацию, влияние на остальную часть вашей программы может быть сведено к минимуму.

Фактическая реализация, которую вы используете для NHibernate, на самом деле не имеет отношения к использованию MVC, за исключением того факта, что ваш пользовательский интерфейс не будет знать о том, как данные хранятся или доступны.

Answer 3

Да. Это звучит примерно так. Я никогда не использовал NHibernate, но ваша модель, разделяющая ваш интерфейс и фасад, звучит хорошо. Конечно, есть много разных способов достичь тех же целей, но ваш выглядит хорошо. :)

Answer 4

Catharsis может иметь то, что вы ищете.