Я пытаюсь освежить свои навыки проектирования шаблонов, и мне любопытно, каковы различия между этими шаблонами? Кажется, что все они одно и то же - инкапсулируют логику базы данных для конкретной сущности, чтобы вызывающий код не знал о базовом уровне персистентности. Из моего краткого исследования все они, как правило, реализуют ваши стандартные методы 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 разных способа сделать одну и ту же вещь.
источник
В мире разработки программного обеспечения существует тенденция (по крайней мере, мне так кажется) изобретать новые имена для известных старых вещей и шаблонов. И когда у нас есть новая парадигма (которая, возможно, немного отличается от уже существующих вещей), она обычно поставляется с целым набором новых имен для каждого уровня. Таким образом, «бизнес-логика» становится «сервисным уровнем» только потому, что мы говорим, что делаем SOA, а DAO становится репозиторием только потому, что мы говорим, что делаем DDD (и каждый из них на самом деле вовсе не является чем-то новым и уникальным, но опять же: новые имена за уже известные понятия собранные в этой же книге). Поэтому я не говорю, что все эти современные парадигмы и аббревиатуры означают ТОЛЬКО одно и то же, но вы действительно не должны быть слишком параноиком по этому поводу. В основном это одни и те же модели, только из разных семей.
источник
Data Mapper vs Table Data Gateway Короче говоря:
В конце они оба будут действовать как посредники между объектами в памяти и базой данных.
источник
У тебя есть хорошая точка зрения. Выберите тот, который вам наиболее знаком. Я хотел бы отметить несколько вещей, которые могут помочь прояснить.
Шлюз табличных данных используется в основном для одной таблицы или представления. Он содержит все операции выбора, вставки, обновления и удаления. Таким образом, Клиент - это таблица или представление в вашем случае. Итак, один экземпляр объекта шлюза табличных данных обрабатывает все строки в таблице. Обычно это связано с одним объектом на таблицу базы данных.
В то время как Data Mapper более независим от любой предметной логики и менее связан (хотя я считаю, что есть связь или нет связи). Это просто промежуточный уровень для передачи данных между объектами и базой данных, сохраняя их независимость друг от друга и от самого преобразователя.
Итак, обычно в маппере вы видите такие методы, как вставка, обновление, удаление, а в шлюзе табличных данных вы найдете getcustomerbyId, getcustomerbyName и т. Д.
Объект передачи данных отличается от двух вышеупомянутых шаблонов, главным образом потому, что это шаблон распределения, а не шаблон источника данных, как вышеупомянутые два шаблона. Используйте его главным образом, когда вы работаете с удаленным интерфейсом и вам нужно сделать свои звонки менее разговорчивыми, поскольку каждый звонок может быть дорогим. Поэтому обычно проектируют DTO, который можно сериализовать по проводам, который может передавать все данные обратно на сервер для применения дальнейших бизнес-правил или обработки.
Я не очень хорошо разбираюсь в шаблоне репозитория, так как до сих пор у меня не было возможности использовать его, но я буду смотреть на ответы других.
источник
Ниже только мое понимание.
TableGateWay / RowDataGateWay : В этом контексте шлюз ссылается на конкретную реализацию, в которой каждый «объект домена» сопоставляется с каждым «шлюзом объекта домена». Например, если у нас есть Person , у нас будет PersonGateway для хранения объекта домена Person в базе данных. Если у нас есть Person, Employee, Customer и т. Д., У нас будут PersonGateway, EmployeeGateway и CustomerGateway. Каждый шлюз будет иметь определенную функцию CRUD для этого объекта, и он не имеет ничего общего с другим шлюзом. Здесь нет повторно используемого кода / модуля. Шлюз может быть далее разделен на RowDataGateway или TableGateway, в зависимости от того, передаете ли вы «id» или «object». Шлюз обычно сравнивают с активной записью. Он связывает вашу модель домена со схемой базы данных.
Репозиторий / DataMapper / DAO : это одно и то же. Все они ссылаются на уровень сохраняемости, который переносит объекты базы данных в модель предметной области. В отличие от шлюза, репозиторий / DataMapper / DAO скрывают реализацию. Вы не знаете, есть ли PersonGateway позади Person. Это может или не может, вам все равно. Все, что вы знаете, это то, что для каждого объекта домена должны поддерживаться операции CRUD. Он разделяет источник данных и модель предметной области.
источник