LLBLGen и шаблон хранилища

Question

Мне было интересно, является ли хорошей идеей создание хранилища на верхнем LLBLGen (адаптере). Я не хочу переигрывать и заново изобретать колесо. Класс DataAccessAdapter может быть своего рода универсальным репозиторием. Он имеет все необходимые вам методы CRUD.

Но с другой стороны для более крупного проекта было бы хорошо иметь слой между вашим ORM и уровнем обслуживания.

Я хотел бы услышать ваше мнение, если вы используете шаблон хранилища с LLBLGen, если да, то почему, если нет, то почему нет.

Если у вас есть реализация, опубликуйте ее, пожалуйста.

Answer 1

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

ИМХО, более важной причиной является применение повсеместного языка. По мере развития вашего приложения / системы вам придется запрашивать данные несколькими способами. Репозиторий может помочь вам инкапсулировать сложные запросы.

В общей реализации ваш потребительский код может выглядеть так:

customerRepo = ServiceLocator.Current.Resolve<IRepository<Customer>>();
var matchingCustomers = customerRepo.GetAll().Where(c => <some complex condition here>);

Используя репозиторий, это выглядело бы так:

customerRepo = ServiceLocator.Current.Resolve<ICustomerRepository>();
var matchingCustomers = myRepo.GetCustomersWithOrdersPendingFor(new DateTime(2010, 12, 31));
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Во втором примере четко указывается цель запроса, что облегчает / ускоряет его идентификацию в будущем.

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

Я обычно делаю следующее:

1. Создайте общий репозиторий (т.е. IRepository)
2. Создайте репозитории для каждого Aggregate Root, реализуя IRepository
3. Добавьте методы запросов по мере необходимости в соответствующий репозиторий
4. Когда хранилище становится слишком раздутым, реорганизуйте запросы в отдельные спецификации запросов

Последнее замечание: однажды я разработал приложение, которое работало как в режиме онлайн, так и в автономном режиме. Самым простым решением было реализовать два конкретных хранилища (с использованием общего интерфейса) и переключаться между ними, когда клиент был подключен / отключен (еще один пример переключения технологии постоянства).

Answer 2

Мы используем репозиторий с LLBLGen, но с самообслуживанием. Мы используем шаблон репозитория для облегчения наших модульных тестов. Для простой вставки / обновления репозиторий просто вызывает метод сохранения переданной сущности. В конечном итоге мы стремимся передавать объекты домена (НЕ объекты LLBLGEN) назад и вперед между репозиторием и бизнес-логикой и иметь только зависимости ORM (LLBLEN, LINQ-To-SQL и т. Д.) В реализованном репозитории.