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

Question

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

• UI зависит от модели, хранилищ и NHibernate
• Хранилища зависит от модели и NHibernate

 

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

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

• UI зависит от модели и фасадов
• Фасад зависит от модели и NHibernate

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

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

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

Thanx

Answer 1

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

• Foo.Ядро

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

• Foo.Persistence

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

• Foo.Web

  • ссылка как Foo.Core и Foo.Persistence
  • HttpModule эталонным для управления NHibernate сессии

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

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