NHibernate с или без Репозитория
Существует несколько подобных вопросов по этому вопросу, я все еще не нашел достаточно причин решить который способ пойти.
Реальный вопрос, действительно ли разумно абстрагировать NHibernate использование шаблона Репозитория, или нет?
Кажется, что единственная причина позади абстракции его состоит в том, чтобы оставить себя опцией заменить NHibernate другим ORM в случае необходимости. Но создание репозиториев и абстракция запросов походят на добавление еще одного слоя и выполнение большой части инфраструктуры вручную.
Одна опция состоит в том, чтобы использовать, выставляют IQueryable к бизнес-слою и использованию LINQ, но на основе моего опыта поддержка LINQ полностью все еще не реализована в NHibernate (запросы просто не всегда работают как ожидалось, и я очень не хочу провести время при отладке платформы).
Хотя ссылка на NHibernate в моем бизнес-слое повреждает мои глаза, это, как предполагается, абстракция доступа к данным отдельно, правильно?
Кто Вы мнения об этом?
3 ответа
Хорошая тишина. Я тоже думал о них несколько дней назад.
На самом деле, попробуйте NHibernate 3.0 alpha (или текущую магистраль), его новый поставщик LINQ намного лучше предыдущих. (Пока я нашел только один метод, который не работает, но вы можете подключить свой собственный механизм, если столкнетесь с чем-то, что он не поддерживает по умолчанию.) У меня не было проблем (пока?) с использованием текущего транка. Вы можете найти «ночную» сборку на сайте http://www.hornget.net/packages/ вместе с сборкой FluentNHibernate против нее. Fluent действительно увеличивает вашу продуктивность, если вы знаете, как им пользоваться. Сообщество SO действительно помогло мне и в этом .
Если вы согласны с тем, что ваш бизнес-уровень напрямую зависит от NHibernate, или вы пишете меньшее приложение, которое остается обслуживаемым без такой абстракции, вы можете обойтись без шаблона репозитория. Однако, если вы все сделаете правильно, это может сэкономить вам много лишнего кода.
Причина абстрагирования заключается не только в том, что вы можете позже заменить NHibernate другим ORM, но и в том, что это хорошая практика благодаря концепции под названием Разделение проблем . Уровень вашей бизнес-логики не должен заботиться или знать, как получить доступ к данным, с которыми он работает. Это упрощает обслуживание приложения или его различных уровней, что также упрощает совместную работу: если X создает уровень доступа к данным, а Y пишет бизнес-логику, им не нужно подробно знать работу друг друга.
Открытие IQueryable - очень хорошая идея, и именно этим сейчас занимаются многие реализации репозиториев. (И я тоже, хотя я предпочел писать его в статическом классе.)
И, конечно, вам придется предоставить некоторые методы для вставки или обновления объекта или методы для начала и завершения транзакций, если вы хочу. (BeginTransaction должен просто вернуть IDisposable , чтобы избежать утечки интерфейса NHibernate, и все будет хорошо.)
Я могу дать вам несколько советов: ознакомьтесь с реализациями SharpArchitecture или FubuMVC Contrib, чтобы получить некоторые идеи о том, как это сделать правильно, и это , как я решил это .
Я бы просто сказал большое ДА! имейте шаблон репозитория, держите вещи абстрактными!
Лично я предпочитаю по-прежнему абстрагировать NHibernate в шаблоне репозитория. Причина в том, что у меня все еще могут быть другие реализации репозитория для кэширования, имитации для модульных тестов и т. Д. И я также использую IQueryable со своим репозиторием, хотя я заставляю IRepository расширять IQueryable, а не раскрывать свойство в IRepository типа IQueryable.
Еще одна точка репозитория. Некоторые люди предлагают не делать его универсальным и иметь идентификацию типа на уровне метода (например, репозиторий.Загрузка). Это, однако, предполагает, что будет единый репозиторий, который знает, как работать со всеми типами. Я не большой поклонник идеи единого монолитного репозитория. Что делать, если вы имеете дело с несколькими базами данных? Или несколько механизмов сохранения? Или некоторые типы данных остаются довольно статичными и могут быть кэшированы, а другие - нет. Вот почему мне нравится отдельный экземпляр репозитория для каждого типа.