NHibernate с репозиторием или без него

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

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

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

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

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

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

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

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

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