Шаблон NHibernate и репозиторий

Question

Какой рекомендуемый подход использовать с шаблоном Nhibernate + Repository?

Вокруг так много разных статей и мнений, что я не уверен, какой путь выбрать. Возьмите, к примеру, эту длинную статью .Он приводит пример объектов Query, но каждый конкретный репозиторий принимает ISession в своем конструкторе.Какое мне дело до сеансов NH в моем BL (бизнес-уровень)?

1. Создать кучу репозиториев, каждый из которых имеет несколько специфических методов?
   По-видимому, это слишком много работы, потому что BL теперь "позволено" знать о NHibernate ( Хранилище - это новый Singleton )?

2. Создатьодин общий репозиторий, но выставьте IQueriable<T> и используйте LINQ в BL
   Время от времени возникает запрос, который LINQ-to-NHibernate не сможет обработать (или мне нужно настроить SQLвручную один раз в сто запросов).Это легко с пользовательскими методами репо, но почти невозможно с кодом, основанным на LINQ.И использование обоих только потому, что LINQ нарушен в некоторых случаях, является бессмысленным.

3. Запрос объектов?
   QueryOver также является специфическим для NH, что означает BLснова осведомлен о реализации DAL.

4. Еще один подход?

Очевидно, мне нужно иметь возможностьуправлять транзакциями где-то , возможно, с помощью паттерна «Единица работы» (хотя существует также много различных реализаций этого).

Answer 1

В мире архитектуры программного обеспечения существует множество противоречивых мнений, и многие из них очень обоснованы.

1) Да, определение хранилища для каждого совокупного корня может быть излишним, но вы можете обнаружить, чтоспособ извлечения данных для этого корня может быть специфичным для него, и вы хотите иметь возможность управлять им в настраиваемом хранилище.Статья Айенде очень красноречива и тесно связана с желанием типичного разработчика «перегружать архитектуру» решениями - часто в ущерб функциональности.

2) Использование LINQ с NHibernate - вариант, но я хотел бы подчеркнуть, что вы должныдайте себе возможность использовать критерии запросов или HQL, если вы сделаете это.На этом этапе вы можете столкнуться с множеством исключений, и вам будет интересно, какова была начальная точка абстракции.

3) QueryOver - это типобезопасная оболочка для запросов критериев, и только она делает ихгораздо привлекательнее для меня.Я так часто сталкиваюсь с критериями абсолютного контроля, которые они предлагают - часто случается, что мне приходится использовать «магические струны».По сути, это сделает NHibernate вашей абстракцией доступа к данным.На самом деле, это была бы лучшая абстракция, чем большинство «репозиториев», потому что большинство из них просто предоставляют методы CRUD ... репозиторий должен иметь возможность обрабатывать спецификации запросов (именно так работает QueryOver).

Какнасколько транзакции идут - это зависит от вашей структуры.На самом деле я не думаю, что это реалистично или выгодно использовать шаблон единицы работы в приложении и скрывать реализацию от него (вы можете абстрагировать его - но какой в ​​этом смысл? - вы действительно собираетесь изменить свой ORM?)

Если вы используете ASP.NET, просто (как минимум) запустите транзакцию в начале запроса, выполните откат исключений и подтвердите в конце.

Если вы используете WinFormsтогда вам, возможно, придется считать срок службы каждой задачи пользовательского интерфейса своей единицей работы.

Answer 2

Сайт, кажется, сейчас недоступен, но мне очень нравится подход Боба Крейвена, и я использовал его в некоторых крупных проектах:

http://blog.bobcravens.com/2010/06/the-repository-pattern-with-linq-to-fluent-nhibernate-and-mysql/ РЕДАКТИРОВАТЬ: Кеш-версия ссылки Google

Он использует шаблоны и шаблон UOW для доступа к данным.

Да, это небольшая боль, когда вам нужно вернуться к SQL, но я использую слой Data Service, который может абстрагировать это.Т.е. уровень обслуживания данных использует общий дао, где это возможно (90% времени), и использует ванильные SQL / другие фреймворки в других местах.