Чем отличаются шаблоны сопоставления данных, шлюз табличных данных (шлюз), объект доступа к данным (DAO) и шаблоны репозитория? - PullRequest
130 голосов
/ 30 апреля 2009

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

Помимо соглашений об именах (например, CustomerMapper против CustomerDAO против CustomerGateway против CustomerRepository), в чем разница, если таковые имеются? Если есть разница, когда бы вы выбрали один из других?

В прошлом я писал бы код, подобный следующему (упрощенно, естественно - я бы обычно не использовал публичные свойства):

public class Customer
{
    public long ID;
    public string FirstName;
    public string LastName;
    public string CompanyName;
}

public interface ICustomerGateway
{
    IList<Customer> GetAll();
    Customer GetCustomerByID(long id);
    bool AddNewCustomer(Customer customer);
    bool UpdateCustomer(Customer customer);
    bool DeleteCustomer(long id);
}

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

Customer cust = CustomerGateway.GetCustomerByID(42);

Похоже, это тот же принцип для шаблонов Data Mapper и Repository; шаблон DAO (который, как мне кажется, аналогичен шлюзу) также, по-видимому, поддерживает шлюзы, специфичные для базы данных.

Я что-то упустил? Кажется немного странным иметь 3-4 разных способа сделать одно и то же.

Ответы [ 5 ]

96 голосов
/ 02 мая 2009

Ваш пример условий; DataMapper, DAO, DataTableGateway и Repository, все имеют схожую цель (когда я использую одну, я ожидаю получить объект Customer), но разные намерения / значение и итоговая реализация.

A Репозиторий "действует как коллекция, за исключением более сложных возможностей запросов" [ Эванс, доменно-управляемый дизайн ] и может рассматриваться как «объекты в фасаде памяти» ( Обсуждение репозитория )

A DataMapper "перемещает данные между объектами и базой данных, сохраняя их независимыми друг от друга и самого преобразователя" ( Fowler, PoEAA, Mapper )

A TableDataGateway - это "шлюз (объект, который инкапсулирует доступ к внешней системе или ресурсу) к таблице базы данных. Один экземпляр обрабатывает все строки в таблице " ( Фаулер, PoEAA, TableDataGateway )

A DAO "отделяет клиентский интерфейс ресурса данных от его механизмов доступа к данным / адаптирует API доступа к конкретному ресурсу данных к общему клиентскому интерфейсу" , разрешающему "доступ к данным механизмы для изменения независимо от кода, который использует данные " ( Sun Blueprints )

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

27 голосов
/ 02 мая 2009

В мире разработки программного обеспечения существует тенденция (по крайней мере, мне так кажется) изобретать новые имена для известных старых вещей и шаблонов. И когда у нас есть новая парадигма (которая, возможно, немного отличается от уже существующих вещей), она обычно приходит с полным набором новых имен для каждого уровня. Таким образом, «бизнес-логика» становится «сервисным уровнем» только потому, что мы говорим, что делаем SOA, а DAO становится репозиторием только потому, что мы говорим, что делаем DDD (и каждый из них на самом деле не является чем-то новым и уникальным, но опять же: новые имена за уже известные понятия собранные в этой же книге). Поэтому я не говорю, что все эти современные парадигмы и аббревиатуры означают ТОЛЬКО одно и то же, но вы действительно не должны быть слишком параноиком по этому поводу. В основном это одни и те же модели, только из разных семейств.

24 голосов
/ 24 июня 2013

Сопоставление данных с шлюзом табличных данных Короче говоря:

Data Mapper получит объект Domain Model (Entity) в качестве параметра и будет использовать его для реализации операций CRUD. Шлюз таблиц данных получит все параметры (в виде примитивов) для методов и ничего не узнает об объекте модели домена (Entity).

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

15 голосов
/ 30 апреля 2009

У вас есть хорошая точка зрения. Выберите тот, который вам наиболее знаком. Я хотел бы отметить несколько вещей, которые могут помочь прояснить.

Шлюз табличных данных используется в основном для одной таблицы или представления. Он содержит все операции выбора, вставки, обновления и удаления. Так что Клиент - это таблица или вид в вашем случае. Таким образом, один экземпляр объекта шлюза табличных данных обрабатывает все строки в таблице. Обычно это связано с одним объектом на таблицу базы данных.

В то время как Data Mapper более независим от любой предметной логики и менее связан (хотя я считаю, что существует связь или нет связи). Это просто промежуточный уровень для передачи данных между объектами и базой данных, сохраняя их независимость друг от друга и самого преобразователя.

Таким образом, обычно в маппере вы видите такие методы, как вставка, обновление, удаление, а в шлюзе табличных данных вы найдете getcustomerbyId, getcustomerbyName и т. Д.

Объект передачи данных отличается от двух вышеупомянутых шаблонов, главным образом потому, что это шаблон распределения, а не шаблон источника данных, как вышеупомянутые два шаблона. Используйте его, главным образом, когда вы работаете с удаленным интерфейсом и вам нужно сделать свои звонки менее разговорчивыми, поскольку каждый звонок может быть дорогим. Поэтому обычно проектируют DTO, который можно сериализовать по проводам, который может передавать все данные обратно на сервер для применения дальнейших бизнес-правил или обработки.

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

0 голосов
/ 13 апреля 2018

Ниже только мое понимание.

TableGateWay / RowDataGateWay : В этом контексте шлюз ссылается на конкретную реализацию, в которой каждый «объект домена» отображается на каждый «шлюз объекта домена». Например, если у нас есть Person , то у нас будет PersonGateway для хранения объекта домена Person в базе данных. Если у нас есть Person, Employee, Customer и т. Д., У нас будут PersonGateway, EmployeeGateway и CustomerGateway. Каждый шлюз будет иметь определенную функцию CRUD для этого объекта, и он не имеет никакого отношения к другому шлюзу. Здесь нет повторно используемого кода / модуля. Шлюз может быть далее разделен на RowDataGateway или TableGateway, в зависимости от того, передаете ли вы «id» или «object». Шлюз обычно сравнивают с активной записью. Он связывает вашу модель домена со схемой базы данных.

Репозиторий / DataMapper / DAO : Это одно и то же. Все они ссылаются на уровень сохраняемости, который переносит объекты базы данных в модель предметной области. В отличие от шлюза, репозиторий / DataMapper / DAO скрывают реализацию. Вы не знаете, есть ли PersonGateway позади Person. Это может или не может, вам все равно. Все, что вы знаете, это то, что для каждого объекта домена должны поддерживаться операции CRUD. Он разделяет источник данных и модель предметной области.

...