¿Cuál es la diferencia entre el Mapeador de datos, el Table Data Gateway (Gateway), el Data Access Object (DAO) y los patrones de repositorio?

133

Estoy tratando de repasar mis habilidades de diseño de patrones, y tengo curiosidad por saber cuáles son las diferencias entre estos patrones. Parece que todos son lo mismo: encapsulan la lógica de la base de datos para una entidad específica, de modo que el código de llamada no tiene conocimiento de la capa de persistencia subyacente. De mi breve investigación, todos ellos implementan típicamente sus métodos CRUD estándar y abstraen los detalles específicos de la base de datos.

Además de las convenciones de nomenclatura (por ejemplo, CustomerMapper vs. CustomerDAO vs. CustomerGateway vs. CustomerRepository), ¿cuál es la diferencia, si la hay? Si hay una diferencia, ¿cuándo elegirías una sobre la otra?

En el pasado, escribiría un código similar al siguiente (simplificado, naturalmente, normalmente no usaría propiedades públicas):

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);
}

y tener una CustomerGatewayclase que implemente la lógica de base de datos específica para todos los métodos. A veces no usaría una interfaz y haría que todos los métodos en CustomerGateway fueran estáticos (lo sé, lo sé, eso lo hace menos verificable) para poder llamarlo así:

Customer cust = CustomerGateway.GetCustomerByID(42);

Este parece ser el mismo principio para los patrones de Data Mapper y Repository; El patrón DAO (que es lo mismo que Gateway, creo) también parece alentar las puertas de enlace específicas de la base de datos.

¿Me estoy perdiendo de algo? Parece un poco extraño tener 3-4 formas diferentes de hacer exactamente lo mismo.

Wayne Molina
fuente

Respuestas:

96

Sus términos de ejemplo; DataMapper, DAO, DataTableGateway y Repository, todos tienen un propósito similar (cuando uso uno, espero recuperar un objeto Cliente), pero diferente intención / significado y la implementación resultante.

Un repositorio "actúa como una colección, excepto con una capacidad de consulta más elaborada" [ Evans, diseño controlado por dominio ] y puede considerarse como un "objeto en la fachada de la memoria" ( discusión del repositorio )

UNA DataMapper "mueve datos entre objetos y una base de datos mientras los mantiene independientes unos de otros y del mapeador" ( Fowler, PoEAA, Mapper )

UNA TableDataGateway es "una puerta de enlace (objeto que encapsula el acceso a un sistema externo o recurso) a una tabla de base de datos. Uno identificadores de instancia todas las filas de la tabla " ( Fowler, PoEAA, TableDataGateway )

Un DAO "separa la interfaz del cliente de un recurso de datos de sus mecanismos de acceso a datos / adapta la API de acceso de un recurso de datos específico a una interfaz de cliente genérica" permitiendo que los "mecanismos de acceso a datos cambien independientemente del código que usa los datos" ( Blueprints de Sun )

El repositorio parece muy genérico, sin exponer ninguna noción de interacción con la base de datos. Un DAO proporciona una interfaz que permite utilizar diferentes implementaciones de bases de datos subyacentes. Un TableDataGateway es específicamente un envoltorio delgado alrededor de una sola mesa. Un DataMapper actúa como intermediario permitiendo que el objeto Modelo evolucione independientemente de la representación de la base de datos (a lo largo del tiempo).

Pierce Hickey
fuente
15
En verdad, no hay una gran diferencia entre DAO y TableDataGateway y en [Fowler, PoEAA] [1] dicen exactamente eso: "[Alur et al.] [2] discute el patrón de Objeto de acceso a datos, que es un Table Data Gateway. .. He usado un nombre diferente, en parte porque veo este patrón como un uso particular del concepto más general de Gateway (466) y quiero que el nombre del patrón lo refleje ". [1]: martinfowler.com/books/eaa.html [2]: books.google.pt/books/about/…
Miguel Gamboa
9
Buen punto. Mi impresión es que la definición proporcionada por PoEAA de TableDataGateway es más estrecha que DataAccessObject. El primero parece implicar un mapeo uno a uno con una tabla de base de datos (relacional), donde un DAO puede actuar como una fachada para múltiples recursos subyacentes no relacionales. El énfasis en un DAO es la capacidad de reemplazar el almacén de datos subyacente, el énfasis en TableDataGateway es la encapsulación de las operaciones de SQL en una sola tabla (no necesariamente de manera neutral / portátil en el almacén de datos).
Pierce Hickey
31

Existe una tendencia en el mundo del diseño de software (al menos eso creo) a inventar nuevos nombres para cosas y patrones antiguos bien conocidos. Y cuando tenemos un nuevo paradigma (que quizás difiere ligeramente de las cosas ya existentes), generalmente viene con un conjunto completo de nuevos nombres para cada nivel. Entonces, "Business Logic" se convierte en "Services Layer" solo porque decimos que hacemos SOA, y DAO se convierte en Repository solo porque decimos que hacemos DDD (y cada uno de ellos no es realmente algo nuevo y único en absoluto, sino de nuevo: nuevos nombres para conceptos ya conocidos reunidos en el mismo libro). Así que no digo que todos estos paradigmas y acrónimos modernos signifiquen EXACTAMENTE lo mismo, pero realmente no deberías ser demasiado paranoico al respecto. En su mayoría, estos son los mismos patrones, solo de diferentes familias.

Dmitry Perets
fuente
44
@MladenMihajlovic, solo porque no entiendas o estés de acuerdo, no significa que esta respuesta no sea válida o que el evento sea correcto.
Cypher
2
@MladenMihajlovic eso no es lo que dice esta respuesta. La última oración lo resume.
Cypher
2
@Cypher ¿Son estos patrones mayormente iguales? No, ellos no son. La implementación del patrón de puerta de enlace es diferente a la implementación del patrón de repositorio. Pueden parecer iguales a simple vista, pero no lo son. Además, como Mladen Mihajlovic señaló correctamente, esta respuesta es bastante incorrecta. La lógica empresarial y la capa de servicios son dos cosas diferentes.
Frederik Krautwald
1
@Cypher No es realmente una cuestión de opinión, sino de hechos. El patrón Gateway fue formulado por Martin Fowler en su PoEAA, y está relacionado principalmente con los patrones Facade o Adapter [GoF]. Las distinciones son que el Gateway está escrito para un uso particular y generalmente no hay una interfaz existente. La puerta de enlace, por lo general, solo involucra dos objetos, y el recurso que se está envolviendo no tiene conocimiento de la puerta de enlace. (continúa ...)
Frederik Krautwald
3
Esto es más un comentario que una respuesta.
Pétur Ingi Egilsson
31

Data Mapper vs Table Data Gateway Para resumir una larga historia:

  • Data Mapper recibirá el objeto Modelo de dominio (Entidad) como parámetro y lo usará para implementar las operaciones CRUD
  • Table Data Gateway recibirá todos los parámetros (como primitivas) para los métodos y no sabrá nada sobre el objeto Modelo de dominio (Entidad).

    Al final, ambos actuarán como mediadores entre los objetos en memoria y la base de datos.

  • nascar
    fuente
    66
    el enlace se ha vuelto obsoleto
    imel96
    15

    Tienes un buen punto. Elija el que está más familiarizado. Me gusta señalar algunas cosas que pueden ayudar a aclarar.

    Table Data Gateway se utiliza principalmente para una sola tabla o vista. Contiene todas las selecciones, inserciones, actualizaciones y eliminaciones. Por lo tanto, el Cliente es una tabla o una vista en su caso. Entonces, una instancia de un objeto de pasarela de datos de tabla maneja todas las filas de la tabla. Generalmente esto está relacionado con un objeto por tabla de base de datos.

    Mientras que Data Mapper es más independiente de cualquier lógica de dominio y está menos acoplado (aunque creo que hay acoplamiento o no acoplamiento). Es simplemente una capa intermedia para transferir los datos entre objetos y una base de datos mientras los mantiene independientes unos de otros y del mapeador.

    Entonces, generalmente en un mapeador, verá métodos como insertar, actualizar, eliminar y en la puerta de enlace de datos de la tabla encontrará getcustomerbyId, getcustomerbyName, etc.

    El objeto de transferencia de datos difiere de los dos patrones anteriores, principalmente porque es un patrón de distribución y no un patrón de fuente de datos como los dos patrones anteriores. Úselo principalmente cuando trabaje con una interfaz remota y necesite hacer que sus llamadas sean menos habladoras, ya que cada llamada puede ser costosa. Por lo tanto, generalmente diseñe un DTO que se pueda serializar a través de un cable que pueda transportar todos los datos de regreso al servidor para aplicar otras reglas o procesos comerciales.

    No estoy bien versado en el patrón de repositorio, ya que no tuve la oportunidad de usarlo hasta ahora, pero buscaré otras respuestas.

    Srikar Doddi
    fuente
    1

    A continuación es solo mi comprensión.

    TableGateWay / RowDataGateWay : en este contexto, Gateway hace referencia a una implementación específica que tiene cada asignación de "objeto de dominio" a cada "puerta de enlace de objeto de dominio". Por ejemplo, si tenemos Person , tendremos una PersonGateway para almacenar el objeto de dominio Person en la base de datos. Si tenemos Person, Employee, Customer, etc., tendremos PersonGateway, EmployeeGateway y CustomerGateway. Cada puerta de enlace tendrá una función CRUD específica para ese objeto y no tiene nada que ver con otra puerta de enlace. No hay código / módulo reutilizable aquí. La puerta de enlace se puede dividir en RowDataGateway o TableGateway, depende de si pasa un "id" o un "objeto". Gateway generalmente se compara con el registro activo. Vincula su modelo de dominio al esquema de la base de datos.

    Repository / DataMapper / DAO : son lo mismo. Todos se refieren a la capa de persistencia que transfiere las entidades de la base de datos al modelo de dominio. A diferencia de la puerta de enlace, el repositorio / DataMapper / DAO oculta la implementación. No sabe si hay una Puerta de acceso de persona detrás de Persona. Puede o no puede que no te importe. Todo lo que sabe es que debe tener operaciones CRUD compatibles con cada objeto de dominio. Desacopla la fuente de datos y el modelo de dominio.

    Hao Lu
    fuente