nHibernate, решение n-Tier + запрос совета

Question

У меня есть шанс разработать слегка сложный проект, и я изучаю различные подходы, которые я могу использовать для решения этого проекта. Как правило, я бы использовал традиционный трехуровневый подход, но, потратив некоторое время на просмотр различных вариантов, у меня возникло предположение, что какой-то ORM может подойти лучше, и я рассматриваю nHibernate. Тем не менее, я ищу некоторые рекомендации по реализации nHibernate и, в частности, как я буду структурировать свои BL и DAL в сочетании с nHibernate.

С помощью nHibernate я бы создавал свои Объекты (или DTO?) И использовал методы nHibernate для моих взаимодействий CRUD - все в моем DAL. Но что я не могу понять, так это то, что Объекты, определенные в DAL, вероятно, будут лучше расположены в BL, то есть там, где можно легко выполнить проверку и другие вещи, и я просто использую DAL из различных ObjectFactory's / ObjectRepositories , К сожалению, кажется, что во многих статьях, которые я читал, об этом не упоминается и не обводится, и я немного запутался.

Каков более приемлемый или более простой способ реализации при использовании nHibernate в 3-уровневой системе? В качестве альтернативы, каков обычный метод представления объектов через бизнес-уровень от уровня данных до презентации?

Answer 1

Я поклонник появления архитектуры, но именно так будет выглядеть моя стартовая архитектура в типичном проекте ntier asp.net mvc, если бы я запускал его сегодня с помощью NHibernate.Я хотел бы попытаться сохранить как можно больше кода домена из контроллера.Следовательно, я бы создал уровень обслуживания / фасад поверх бизнес-уровня, к которому обращается контроллер (или код).Я бы разделил свои объекты на два типа: 1) объекты с деловым поведением, которые используются на стороне записи, и 2) объекты ViewModel / DTO, которые используются для отображения данных и получения начального ввода данных.Эти DTO будут иметь все специфичные для представления проблемы, такие как простые атрибуты проверки и т. Д. DTO могут иметь свои собственные отображения NHibernate, или они могут проецироваться с использованием функции AliasToBean NHibernate.Они будут сопоставлены с бизнес-объектами, как только они пройдут контроллер в операциях.

Что касается уровня доступа к данным, я бы, вероятно, использовал бы NHibernate непосредственно на уровне обслуживания.Я бы не использовал шаблон репозитория, если бы не знал, что должен иметь возможность менять ORM.NHibernate уже абстракция постоянства.Помещение хранилища поверх него заставляет вас отказаться от множества функций.

Answer 2

Я подозреваю, что вы обдумываете это. nHibernate в основном довольно простой инструмент; что он в основном делает, так это управляет сериализацией ваших записей в вашей базе данных и из аналогично структурированных объектов в вашей модели данных. Это в основном это. Ничто не говорит о том, что вы не можете инкапсулировать свои объекты Hibernate в объекты бизнес-уровня для проверки; это прекрасно. Но поймите, что операции валидации и сериализации принципиально различны; Hibernate управляет компонентом сериализации и делает это довольно хорошо. Сериализуемые в Hibernate объекты можно считать «атомарными».

По сути, вам нужно следующее: nHibernate - это ваш уровень доступа к данным. (Конечно, у вас могут быть другие методы доступа к данным на уровне доступа к данным, но если вы собираетесь использовать Hibernate, вам следует придерживаться базового дизайна данных Hibernate, то есть простых объектов, которые выполняют относительно прямое отображение записей к объекту.) Если ваш дизайн требует, чтобы вы использовали другой дизайн (глубоко составленные объекты, зависящие от нескольких перекрывающихся таблиц), который плохо отображается в Hibernate, вам, возможно, придется отказаться от использования Hibernate; в противном случае, просто используйте простой подход POCO, подразумеваемый nHibernate.

Answer 3

Мой личный опыт работы с nHibernate заставил меня решить, что уровень доступа к данным становится настолько тонким, что мне никогда не было смысла отделять его от бизнес-логики.Большая часть вашего кода доступа к данным уже разделена на XML-файлы (или различные другие отличительные методы, такие как Fluent nHibernate), а поскольку объединения обрабатываются почти прозрачно, ваши запросы с использованием объектов критериев редко превышают несколько строк.

Answer 4

Мои 02 цента (поскольку нет ответа на все вопросы):

DAL должен отвечать ТОЛЬКО за извлечение и сохранение данных.

вы можете иметь библиотеку, содержащуюваша Модель (объекты), которые заполнены DAL, но слабо связаны (теоретически вы должны быть в состоянии написать новый DAL, используя другую технологию, и подключить его вместо NHIBERNATE, даже если вы не собираетесь)

для клиента <-> BL talk, я бы серьезно посоветовал views / dto's избегать связывания модели с клиентом (поверьте, я .. я убираю подобное приложение, и это ад)

в любом случае .. Я говорю о ситуации, которую мы используем здесь, которая имеет следующую структуру:

клиент (winforms и web) <-> View / Presenter <-> WCF Services используя сообщения <-> BL<-> DAL

Answer 5

У меня есть приложения на основе NHibernate, и хотя это лучше, чем у большинства DAL, я не могу больше рекомендовать использовать NHibernate. Изощренность, необходимая для работы с сеансом для выполнения любого сложного приложения, просто абсурдна. Для создания простых приложений NHibernate очень прост для корпоративных приложений, сложность не по графику.

На этом этапе я решил решить вопрос доступа к данным с 3 различными вариантами в зависимости от области применения, используя базу данных документов (в частности, в настоящее время Raven) для полномасштабного применения, для средних объемов доступа к данным с использованием LinqToSql и для тривиального доступ Я на самом деле использую сырые соединения ADO.NET с большим успехом.

Для справки, эти утверждения сделаны после того, как я потратил более двух лет на разработку с использованием NHibernate, и каждый раз, когда я чувствовал, что полностью понял NHibernate, я сталкивался с каким-то новым ограничением или гигантским гаечным ключом иметь дело с. Это также привело меня к осознанию того, что я начал разрабатывать приложения в отношении NHibernate, что является одной из главных причин, по которой я использую ORM, чтобы не диктовать дизайн моих приложений базой данных.

Отсутствие необходимости иметь дело с управлением сессиями со сложностью NHibernate было для меня одним из самых больших преимуществ при переходе на RavenDB. В Raven вам практически не нужно управлять сессией, кроме случаев, когда вы проводите экстремальную оптимизацию производительности или работаете с пакетными действиями.