Шаблон репозитория по сравнению с DAL

Вы - определенно не тот, который путает вещи.:-)

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

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

репозиторий с моей точки зрения является просто явно указанным слоем доступа к данным. Или другими словами стандартизованный способ для реализации Уровня доступа к данным. Существуют некоторые различия между различными реализациями репозитория, но понятие является тем же.

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

Одна проблема реализации, которая, кажется, делает их отличающимися, то, что репозиторий часто создается с методами, которые берут спецификацию. Репозиторий возвратит данные, которые удовлетворяют ту спецификацию. Самый традиционный DALs, который я видел, будет иметь больший набор методов, где метод возьмет любое количество параметров. В то время как это может походить на небольшую разницу, это - большая проблема при вводе областей Linq и Expressions. Наш интерфейс репозитория по умолчанию похож на это:

public interface IRepository : IDisposable
{
    T[] GetAll<T>();
    T[] GetAll<T>(Expression<Func<T, bool>> filter);
    T GetSingle<T>(Expression<Func<T, bool>> filter);
    T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
    void Delete<T>(T entity);
    void Add<T>(T entity);
    int SaveChanges();
    DbTransaction BeginTransaction();
}

действительно ли это - DAL или репозиторий? В этом случае я предполагаю оба.

Kim

Репозиторий является шаблоном, который может быть применен многими различными способами, в то время как уровень доступа к данным несет очень ясную ответственность: DAL должен знать, как соединиться с Вашим хранением данных для выполнения операций CRUD.

репозиторий А может быть DAL, но он может также находиться перед DAL и действовать как мост между слоем бизнес-объекта и слоем данных. То, какая реализация используется, собирается варьироваться от проекта до проекта.

Значительные различия - то, что ДАО является универсальным способом иметь дело с персистентностью для любого объекта в Вашем домене. Репозиторий, с другой стороны, только имеет дело с совокупными корнями.

Мое личное мнение - то, что это - все об отображении, см.: http://www.martinfowler.com/eaaCatalog/repository.html . Таким образом, вывод/вход из репозитория является объектами области, которые на DAL могли быть чем-либо. Для меня, который является важным дополнением/ограничением, поскольку можно добавить реализацию репозитория для database/service/whatever с другим расположением, и у Вас есть ясное место для концентрации на выполнении отображения. Если Вы не должны были использовать то ограничение и иметь отображение в другом месте, то наличие различных способов представить данные может повлиять на код в местах, которые это не должно изменять.

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

Из того, что я понимаю, что они могут иметь в виду в основном то же самое - но именование варьируется на основе контекста.

, Например, у Вас мог бы быть класс Dal/Dao, который реализует интерфейс IRepository.

Dal/Dao является термином слоя данных; более высокие уровни Вашего приложения думают с точки зрения Репозиториев.

Таким образом в большей части (простого) ДАО случаев реализация Репозитория?

, Насколько я понимаю, кажется, что ДАО имеет дело точно с доступом дб (CRUD - Никакой не выбирает хотя?!), в то время как Репозиторий позволяет Вам абстрагировать целый доступ к данным, возможно, будучи фасадом для нескольких ДАО (возможно, различные источники данных).

я на правильном пути?

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

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

Я могу даже пойти так далеко и заявить, что , если только Шаблон репозитория используется вместе с шаблоном спецификации, это не совсем «Репозиторий», а DAL. Надуманный пример в псевдокоде:

specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)

assert that specification200.isSpecialCaseOf(specification100)

specificationAge = new AccountIsOlderThan('2000-01-01')

combinedSpec = new CompositeSpecification(
    SpecificationOperator.And, specification200, specificationAge)

for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
    assert that account.Created < '2000-01-01'
    assert that account.Orders.Count > 200

См. Эссе по спецификациям Фаулера для подробностей (это то, на чем я основывался выше).

DAL будет иметь специализированные методы, такие как

IoCManager.InstanceFor<IAccountDAO>()
    .GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')

Вы можете увидеть, как это может быстро стать громоздким, особенно потому, что вам нужно определить каждый из интерфейсов DAL / DAO с этим подходом и реализовать метод запроса DAL.

В .NET запросы LINQ могут ] может быть одним из способов реализации спецификаций, но комбинирование Спецификации (выражений) может быть не таким гладким, как в случае собственного решения. Некоторые идеи для этого описаны в этом вопросе SO .

s Очерк спецификаций для подробностей (это то, на чем я основывался выше).

DAL будет иметь специализированные методы, такие как

IoCManager.InstanceFor<IAccountDAO>()
    .GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')

. Вы можете видеть, как это может быстро стать громоздким, особенно если вы должны определить каждый из DAL / DAO взаимодействует с этим подходом и реализуют метод запроса DAL.

В .NET запросы LINQ могут быть одним из способов реализации спецификаций, но объединение спецификаций (выражений) может не будет такой гладкой, как с домашним раствором. Некоторые идеи для этого описаны в этом вопросе SO .

s Очерк спецификаций для подробностей (это то, на чем я основывался выше).

DAL будет иметь специализированные методы, такие как

IoCManager.InstanceFor<IAccountDAO>()
    .GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')

. Вы можете видеть, как это может быстро стать громоздким, особенно если вы должны определить каждый из DAL / DAO взаимодействует с этим подходом и реализуют метод запроса DAL.

В .NET запросы LINQ могут быть одним из способов реализации спецификаций, но объединение спецификаций (выражений) может не будет такой гладкой, как с домашним раствором. Некоторые идеи для этого описаны в этом вопросе SO .

особенно потому, что вам нужно определить каждый из интерфейсов DAL / DAO с этим подходом и , реализующие метод запроса DAL.

В .NET запросы LINQ могут быть одним из способов реализации спецификации, но комбинирование Спецификации (выражений) может быть не таким гладким, как с домашним решением. Некоторые идеи для этого описаны в этом вопросе SO .

особенно потому, что вам нужно определить каждый из интерфейсов DAL / DAO с этим подходом и , реализующие метод запроса DAL.

В .NET запросы LINQ могут быть одним из способов реализации спецификации, но комбинирование Спецификации (выражений) может быть не таким гладким, как с домашним решением. Некоторые идеи для этого описаны в этом вопросе SO .

Во внешнем мире (т.е. в клиентском коде) репозиторий такой же, как и DAL, за исключением того, что:

(1) его методы вставки/обновления/удаления ограничены тем, что объект контейнера данных является параметром.

(2) для операции чтения может потребоваться простая спецификация, такая как DAL (например, GetByPK) или расширенная спецификация.

Внутренне он работает с уровнем Data Mapper Layer (например, с контекстом фреймворка сущностей и т.д.) для выполнения реальной операции CRUD.

Какой паттерн репозитория не означает:-

Кроме того, я видел, как люди часто путаются, что в качестве реализации шаблона репозитория помимо методов вставки/обновления/удаления в БД реализован отдельный метод Save, который фиксирует все изменения в памяти, выполненные методами вставки/обновления/удаления. Мы можем иметь метод Save в репозитории определённо, но это не обязанность репозитория изолировать методы CUD (Create, Update, Delete) и персистентности (которые выполняют реальную операцию записи/изменения в БД), а ответственность за шаблон Unit Of Work.

Надеюсь, это поможет!

.

Репозиторий - это шаблон, это способ реализовать вещи стандартизированным способом для повторного использования кода, насколько это возможно.