В чем разница между Data Mapper, Table Data Gateway (шлюз), Data Access Object (DAO) и шаблонами репозитория?
Я пытаюсь освежить свои навыки дизайна шаблона, и мне любопытно, каковы различия между этими шаблонами? Все они кажутся одинаковыми-инкапсулируют логику базы данных для определенной сущности, поэтому вызывающий код не знает о базовом уровне сохраняемости. Из моего краткого исследования все они обычно реализуют ваши стандартные методы 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 static (я знаю, я знаю, что делает его менее тестируемым), поэтому я могу назвать его так:
Customer cust = CustomerGateway.GetCustomerByID(42);
это, кажется, тот же принцип для шаблонов отображения данных и репозитория; шаблон DAO (что то же самое, что шлюз, я думаю?) также, по-видимому, поощряются шлюзы для конкретных баз данных.
Я что-то пропустила? Кажется немного странным иметь 3-4 разных способа делать одно и то же.
5 ответов:
ваши примеры терминов; DataMapper, DAO, DataTableGateway и репозиторий, все имеют одинаковую цель (когда я использую один, я ожидаю получить обратно объект Customer), но разные намерения/смысл и результирующая реализация.
A хранилище "действует как коллекция, за исключением более сложной возможности запроса" [Эванс, Домен Управляемый Дизайн] и может рассматриваться как "объекты на фасаде памяти" (хранилище обсуждение)
A DataMapper"перемещает данные между объектами и базой данных, сохраняя их независимыми друг от друга и самого картографа" (Фаулер, PoEAA, Маппер)
A TableDataGateway и "шлюз (объект, который инкапсулирует доступ к внешней системе или ресурсу) к таблице базы данных. Один экземпляр обрабатывает все строки в таблице" (Fowler, PoEAA, TableDataGateway)
A Дао "отделяет клиентский интерфейс ресурса данных от его механизмов доступа к данным / адаптирует API доступа конкретного ресурса данных к общему клиентскому интерфейсу" позволяет "механизмы доступа к данным для изменения независимо от кода, который использует данные" (Солнечная Проектов)
репозиторий кажется очень общим, не раскрывая понятия взаимодействия с базой данных. DAO предоставляет интерфейс включение различных реализаций базовых баз данных для использования. TableDataGateway-это тонкая обертка вокруг одного стола. DataMapper действует как посредник, позволяющий объекту модели развиваться независимо от представления базы данных (с течением времени).
в мире дизайна программного обеспечения существует тенденция (по крайней мере, я так чувствую) изобретать новые имена для известных старых вещей и шаблонов. И когда у нас есть новая парадигма (которая, возможно, немного отличается от уже существующих вещей), она обычно поставляется с целым набором новых имен для каждого уровня. Таким образом," бизнес-логика "становится" уровнем сервисов " только потому, что мы говорим, что делаем SOA, а DAO становится репозиторием только потому, что мы говорим, что делаем DDD (и каждый из них на самом деле не является чем-то новым и уникальным, но опять же: новые названия для уже известных понятий собраны в той же книге). Поэтому я не говорю, что все эти современные парадигмы и аббревиатуры означают одно и то же, но вы действительно не должны быть слишком параноидальными. В основном это одни и те же модели, только из разных семей.
Data Mapper vs Table Data Gateway Чтобы сделать длинную историю короткой:
Сопоставитель данных получит объект модели домена (сущность) как param и будет использовать его для реализации операций CRUD шлюз данных таблицы будет получать все параметры(как примитивы) для методов и ничего не будет знать об объекте модели домена (сущности). В конце концов оба они будут выступать в качестве посредника между объектами в памяти и база данных.
У вас есть хороший момент. Выберите тот, с которым вы наиболее знакомы. Я хотел бы отметить несколько вещей, которые могут помочь прояснить.
шлюз табличных данных используется в основном для одной таблицы или представления. Он содержит все выделяет, вставляет, обновляет и удаляет. Таким образом, клиент-это таблица или представление в вашем случае. Таким образом, один экземпляр объекта шлюза данных таблицы обрабатывает все строки в таблице. Обычно это связано с одним объектом в таблице базы данных.
во время отображения данных более независим от любой логики домена и менее связан (хотя я считаю, что либо есть связь, либо нет связи). Это просто промежуточный уровень для передачи данных между объектами и базой данных, сохраняя их независимыми друг от друга и самого картографа.
таким образом, как правило, в mapper вы видите такие методы, как insert, update, delete, а в Table data gateway вы найдете getcustomerbyId, getcustomerbyName и т. д.
объект передачи данных отличается от выше двух шаблонов, главным образом потому, что это шаблон распределения, а не шаблон источника данных, как выше двух шаблонов. Используйте его в основном, когда вы работаете с удаленным интерфейсом и должны сделать ваши звонки менее болтливыми, поскольку каждый вызов может стать дорогим. Поэтому обычно разрабатывают DTO, который может быть сериализован по проводу, который может переносить все данные обратно на сервер для применения дальнейших бизнес-правил или обработки.
Я не очень хорошо разбираюсь в шаблоне репозитория, так как у меня не было возможности использовать до сих пор, но будет смотреть на другие ответы.
ниже только мое понимание.
TableGateWay / RowDataGateWay: В этом контексте шлюз ссылается на конкретную реализацию, в которой каждый" объект домена "сопоставляется с каждым"шлюзом объектов домена". Например, если у нас есть человек, тогда у нас будет PersonGateway сохранить объект домена человека в базе данных. Если у нас есть человек, сотрудник, клиент и т. д., У нас будет PersonGateway, EmployeeGateway и CustomerGateway. Каждый шлюз будет иметь определенную функцию CRUD для этого объекта и не имеет ничего общего с другими воротами. Здесь нет многоразового кода / модуля. Шлюз может быть дополнительно разделен на RowDataGateway или TableGateway, в зависимости от того, передаете ли вы "идентификатор" или "объект". Шлюз обычно сравнивают с активной записью. Он связывает вашу модель домена со схемой базы данных.
Repository / DataMapper / DAO: Это одно и то же. Все они относятся к уровню сохраняемости, который передает объекты базы данных в модель домена. В отличие от шлюза, репозиторий/DataMapper/DAO скрывают реализацию. Вы не знаете, если есть PersonGateway позади человека. Это может быть, а может и нет, вам все равно. Все, что вы знаете, это то, что он должен иметь операции CRUD, поддерживаемые для каждого объекта домена. Он отделяет источник данных и модель домена.
Comments