NHibernate с или без хранилища

Question

Есть несколько похожих вопросов по этому вопросу, но я до сих пор не нашел достаточно причин, чтобы решить, в какую сторону идти.

Реальный вопрос в том, разумно ли абстрагировать NHibernate с помощью шаблона репозитория , или не ?

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

Одним из вариантов является использование expose IQueryable<T> для бизнес-уровня и использование LINQ, но из моего опыта поддержка LINQ все еще не полностью реализована в NHibernate (запросы просто не всегда работают должным образом, и я ненавижу тратить время на отладка фреймворка).

Хотя ссылки на NHibernate в моем бизнес-уровне причиняют мне боль, это должна быть абстракция доступа к данным, не так ли?

Что вы думаете по этому поводу?

Answer 1

Хорошие вопросы. Я тоже думал о них несколько дней назад.

На самом деле, попробуйте NHibernate 3.0 alpha (или текущий транк), его новый поставщик LINQ намного превосходит предыдущие. (До сих пор я нашел только один метод, который не работает, но можно подключить свой собственный механизм, если вы столкнетесь с чем-то, что он не поддерживает по умолчанию.) У меня не было проблем (пока?) С использованием текущего транка. На сайте http://www.hornget.net/packages/ можно найти "ночные" сборки, а также сборку FluentNHibernate. Свободное владение действительно увеличивает вашу производительность, если вы знаете, как его использовать. Сообщество SO действительно помогло мне с этим .

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

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

Представление IQueryable<T> - очень хорошая идея, и это именно то, что многие реализации репозитория делают прямо сейчас. (И я тоже, хотя я предпочел написать это в статическом классе.) И, конечно, вам нужно будет предоставить некоторые методы для вставки или обновления сущности или методы для начала и совершения транзакций, если вы хотите. (BeginTransaction должна просто вернуть IDisposable, чтобы избежать утечки интерфейса NHibernate, и это будет хорошо.)

Я могу дать вам несколько указаний: проверить реализации SharpArchitecture или FubuMVC Contrib, чтобы получить некоторые идеи о том, как сделать это правильно, и это , как я решил это .

Answer 2

Я лично предпочитаю по-прежнему абстрагировать NHibernate в шаблон хранилища. Причина в том, что у меня все еще могут быть другие реализации репозитория для кэширования, макетирования для модульных тестов и т. Д. И я также использую IQueryable с моим репозиторием, хотя я заставляю IRepository расширять IQueryable, а не выставлять свойство в IRepository типа IQueryable.

Еще одна точка хранилища. Некоторые люди предлагают не делать его общим и иметь идентификацию типа на уровне метода (то есть repository.Load). Это, однако, предполагает, что будет один репозиторий, который знает, как обращаться со всеми типами. Я не большой поклонник этого понятия единого монолитного хранилища. Что делать, если вы имеете дело с несколькими базами данных? Или множественные механизмы персистенции? Или некоторые типы данных остаются довольно статичными и могут быть кэшированы, но другие не могут. Вот почему мне нравится отдельный экземпляр репозитория для каждого типа.

Answer 3

Я бы просто сказал большое ДА! иметь шаблон репозитория, держать вещи абстрактными!