Шаблон хранилища против DAL

Ответ 1

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

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

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

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

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

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

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 или репозиторием? В этом случае я думаю, что и то и другое.

Ким

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

Я даже могу зайти так далеко и указать, что если шаблон репозитория не используется вместе с шаблоном Specification, это не действительно "репозиторий", а 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

Подробнее см. Спецификация спецификаций Fowler (что я основал выше).

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

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

Итак, в большинстве (простых) случаев DAO является реализацией репозитория?

Насколько я понимаю, DAO имеет дело с доступом к db (CRUD - No selects хотя?!), в то время как репозиторий позволяет вам абстрагироваться от всего доступа к данным, возможно, являясь фасадом для нескольких DAO (возможно, для разных источников данных).

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

Ответ 10

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

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

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

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

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

Кроме того, я видел, как люди часто путаются, чтобы иметь отдельный метод Save в качестве образца образца шаблона репозитория, помимо методов Insert/Update/Delete, которые фиксируют все изменения в памяти, выполняемые методами вставки/обновления/удаления, база данных. Мы можем иметь метод сохранения определенно в репозитории, но не репликация заключается в том, чтобы изолировать CUD (создание, обновление, удаление) в памяти и методы сохранения (которые выполняют фактическую операцию записи/изменения в базе данных), но ответственность за образец работы.

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

Ответ 11

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