nHibernate, решение n-уровня + запрос на консультацию

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

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

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

источник

2010-10-20 SeanCocteau

FWIW быть очень осторожны в процессе принятия решений, поскольку это может иметь длительные последствия для вашей карьеры если вы потерпите неудачу. У меня был более чем год опыта работы с NHibernate, закрывшись за 2 года до того, как я когда-либо имел полное корпоративное приложение в производстве с использованием NHibernate, а не тривиальное приложение. Если бы возникла такая возможность, что я мог бы сделать это раньше, я уверен, что буду иметь, но с задним числом. Я не думаю, что смог бы добиться успеха проекта, пока у меня не будет почти двухлетнего опыта работы с NHibernate , –

Итак, какого рода поиски я ищу здесь? Идея nHibernate состоит в том, чтобы сэкономить время в целом и облегчить проблемы, а не увеличивать их. Atm, я понимаю, что использование WCF подрывает некоторые функции nHibernate, но с использованием шаблона Respository и DTO оборачивается этим, мой план состоит в том, чтобы определить мой бизнес-объект в BL вместе с файлами сопоставления, а затем использовать шаблон Respository в DAL, это хороший план? – SeanCocteau

Я очень впечатлен nhibernate, теперь у нас есть средний или слегка сложный проект (asp.net MVC), но потребовалось некоторое время, чтобы получить hql. (иногда нам приходилось обманывать и использовать необработанный SQL - из-за отсутствия знаний), я также использовал классическое сопоставление/сущность bindind со старыми scool php/asp и sql spagetti, а в других проектах мы пробовали ADO.NET, а затем Объекты данных Java. Теперь о Нибенрате, который произвел на меня наибольшее впечатление. –

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

источник

2010-10-20 16:34:09

Это как-то, как я думаю, что все может закончиться, на данный момент мое мышление что-то вроде этого ... – SeanCocteau

Я создаю свой POCO, представляющий мои бизнес-объекты в бизнес-слое, например. Клиент, Заказ и т. Д., А также добавление сопоставлений Hibernate. Затем я использую шаблон IRespository, создающий репозиторий для каждого соответствующего объекта, например. CustomerRespository, OrderRespository и т. Д., Который убирает любой nHibernate guff, позволяющий WCF легко передавать объект? В моем слое данных я включаю соответствующее управление сеансом Hibernate Session (через Singleton?) И AbstractRepository, которое использует методы nHibernate на фактическом уровне данных. – SeanCocteau

Это заключение, к которому я прихожу (быстро), и эта польза от реферата DAL по-прежнему остается, BL будет размещать бизнес-объекты, файлы сопоставления и связанные с ними репозитории – SeanCocteau

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

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

источник

2010-10-20 16:35:45

-1 хочу, чтобы я мог -10 для утверждения " nHibernate в основном довольно простой инструмент «это совершенно неточно. Управление сеансами NHibernate является одним из самых сложных отношений, с которыми я когда-либо сталкивался при разработке программного обеспечения. –

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

@Noctris. Мне действительно нужно было бы согласиться на этот момент для ключевого слова Deeply , с NHibernate вы редко когда-либо захотите пройти более 2-3 вложенных объектов, потому что после этого ваш sql-запрос может оказаться в десятке объединений. Это очень легко увидеть, как только вы начнете выполнять наследование, когда Contact наследует от Person и Employee наследует от контакта, объект Person имеет коллекцию адресов и телефонов. На данный момент у вас есть 5 или 7 таблиц в зависимости от того, моделируете ли вы коллекцию как много-ко-многим или нет. –

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

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

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

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

источник

2010-10-20 16:56:15

Я не уверен, какую сложность вы говорите, когда речь заходит о сессии. По крайней мере, для веб-приложений я обнаружил, что HybridSessionBuilder, что вы можете видеть, что люди, использующие веб-сайты в разных блогах nHibernate, делают управление сеансами довольно безболезненным. http://jeffreypalermo.com/blog/use-this-nhibernate-wrapper-to-keep-your-repository-classes-simple/ –

Попробуйте реализовать длинный шаблон сохранения с NHibernate в веб-среде, через 2 года я отказался и принял это просто не принципиально возможно с NHibernate. –

Этот парень, кажется, думает, что он это сделал: http://dotnetchris.wordpress.com/2009/12/18/implementing-nhibernate-long-conversation-with-no-httpmodules-or-aop-build-time-weaving/ –

Я поклонник разрешения архитектуры возникнуть, но это то, что моя первоначальная архитектура будет выглядеть на типичном проекте asp.net mvc ntier, если я начал его сегодня с помощью NHibernate.

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

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

источник

2010-10-20 17:05:38

«Помещение репозитория над ним заставляет вас отказаться от множества функций». Я бы не согласился с этим благочестивым, реализация шаблона репозитория поверх него - отличный способ получить доступ к добре NHibernate тривиально. У меня есть блог в этой части, который является лучшим, что я когда-либо делал с NHibernate. http://dotnetchris.wordpress.com/2010/03/15/creating-a-common-generic-and-extensible-nhiberate-repository-version-2/ –

Когда я сказал образец репозитория, я больше думал о строках от агностического ORM. Я вижу, что ваш - это NHibernate, поэтому вы не отказываетесь от каких-либо функций. Я бы использовал что-то вроде этого или, скорее, шаблон объекта запроса (который в основном представляет собой набор ультраспециальных репозиториев). –

Мои 02 центов (так как нет на-ответ подходит всем):

DAL должны только нести ответственность за retrievel данных и настойчивости.

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

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

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

клиента (WinForms и веб) < -> Просмотр/Presenter < -> WCF услуги с использованием сообщений < -> BL < -> DAL

источник

2010-10-20 17:11:51 Noctris

nHibernate, решение n-уровня + запрос на консультацию

ответ

Смежные вопросы