¿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?

StackOverflow https://stackoverflow.com/questions/804751

Pregunta

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, escribía 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 clase CustomerGateway que implementa la lógica de base de datos específica para todos los métodos. A veces no uso una interfaz y hago que todos los métodos en el CustomerGateway sean estáticos (lo sé, lo sé, eso lo hace menos comprobable), por lo que puedo 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 algo? Parece un poco extraño tener 3-4 formas diferentes de hacer exactamente lo mismo.

¿Fue útil?

Solución

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

Un Repositorio " actúa como una colección, excepto con una capacidad de consulta más elaborada [ Evans, Domain Driven Design ] y pueden considerarse como objetos " en la fachada de memoria " ( Discusión del repositorio )

Un DataMapper " mueve datos entre objetos y una base de datos mientras los mantiene independientes entre sí y con el mapeador en sí mismo " ( Fowler, PoEAA, Mapper )

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

Un DAO " separa la interfaz de 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 " mecanismos de acceso a datos para cambiar independientemente del código que utiliza los datos " ( Planos de sol )

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 una envoltura delgada alrededor de una sola tabla. 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).

Otros consejos

Hay 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. Así que " lógica de negocios " se convierte en " Capa de servicios " solo porque decimos que hacemos SOA, y DAO se convierte en Repositorio 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.

Tienes un buen punto. Elija el que le resulte más familiar. Me gustaría señalar algunas cosas que pueden ayudar a aclarar.

La puerta de enlace de datos de tabla 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. Por lo tanto, una instancia de un objeto de puerta de enlace de datos de tabla maneja todas las filas de la tabla. Por lo general, 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 se mantienen independientes entre sí y con el mapeador en sí.

Por lo general, en un asignador, usted ve 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 está trabajando con una interfaz remota y necesita hacer que sus llamadas sean menos habladoras, ya que cada llamada puede resultar costosa. Por lo tanto, por lo general, 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 más reglas comerciales o procesamiento.

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

A continuación es solo mi entendimiento.

TableGateWay / RowDataGateWay : En este contexto, Gateway hace referencia a una implementación específica que tiene cada " objeto de dominio " asignación a cada " puerta de enlace de objeto de dominio " ;. Por ejemplo, si tenemos Persona , entonces tendremos un PersonGateway para almacenar el objeto de dominio Persona en la base de datos. Si tenemos Persona, Empleado, Cliente, etc., tendremos PersonGateway, EmployeeGateway y CustomerGateway. Cada puerta de enlace tendrá una función CRUD específica para ese objeto y no tendrá 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, dependiendo de si pasas un " id " o un "objeto". Gateway se suele comparar con el registro activo. Vincula su modelo de dominio al esquema de la base de datos.

Repositorio / 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 sabes si hay un PersonGateway detrás de Person. 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.

No afiliado a StackOverflow
scroll top