c# - example - ¿Cuál es la diferencia entre Data Mapper, Table Data Gateway(Gateway), Data Access Object(DAO) y los patrones de Repository?
dao vs repository (5)
Debajo está solo mi entendimiento.
TableGateWay / RowDataGateWay : en este contexto, Gateway se refiere a una implementación específica que tiene cada asignación de "objeto de dominio" a cada "puerta de enlace de objetos de dominio". Por ejemplo, si tenemos Person , 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á 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. Ata 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 entidades de 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 una Puerta de persona detrás de Persona. Puede, o no, no te importa. Todo lo que sabe es que debe tener operaciones CRUD compatibles para cada objeto de dominio. Desvincula la fuente de datos y el modelo de dominio.
Estoy tratando de repasar mis habilidades de patrones de diseño, y tengo curiosidad por saber cuáles son las diferencias entre estos patrones. Todos parecen ser lo mismo: encapsulan la lógica de la base de datos para una entidad específica, por lo que el código de llamada no tiene conocimiento de la capa de persistencia subyacente. A partir de mi breve investigación, todos ellos suelen implementar sus métodos estándar CRUD 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 corresponde? 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 tiene una clase CustomerGateway que implementa la lógica de base de datos específica para todos los métodos. A veces no utilizaría una interfaz y haría estáticos todos los métodos en el CustomerGateway (lo sé, lo sé, eso lo hace menos comprobable) para que pueda 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, ¿no es así?) también parece alentar las pasarelas 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.
Hay una tendencia en el mundo del diseño de software (al menos así lo creo) a inventar nuevos nombres para antiguas cosas y patrones bien conocidos. Y cuando tenemos un nuevo paradigma (que tal vez difiera ligeramente de las cosas ya existentes), por lo general viene con un conjunto completo de nuevos nombres para cada nivel. Así que "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 en realidad algo nuevo y único, sino de nuevo: nuevos nombres para conceptos ya conocidos reunidos en el mismo libro). Así que no estoy diciendo que todos estos paradigmas y acrónimos modernos significan EXACTAMENTE lo mismo, pero realmente no deberían ser demasiado paranoicos al respecto. En su mayoría, estos son los mismos patrones, solo de diferentes familias.
Sus términos de ejemplo; DataMapper, DAO, DataTableGateway y Repository, todos tienen un propósito similar (cuando uso uno, espero recuperar un objeto Customer), 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, Domain Driven Design ] y puede considerarse como una "fachada de objetos en la memoria" ( Discusión del repositorio )
Un DataMapper "mueve los datos entre los objetos y una base de datos manteniéndolos independientes entre sí y del propio mapeador" ( Fowler, PoEAA, Mapper )
Un TableDataGateway es "un Gateway (objeto que encapsula el acceso a un sistema o recurso externo) a una tabla de base de datos. Una instancia maneja todas las filas en 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 una API de acceso a recursos de datos específicos a una interfaz de cliente genérica" permitiendo "que los mecanismos de acceso a datos cambien independientemente del código que usa los datos" ( Sun Blueprints )
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 contenedor delgado alrededor de una sola tabla. Un DataMapper actúa como un intermediario que permite que el objeto Model evolucione independientemente de la representación de la base de datos (a lo largo del tiempo).
Tienes un buen punto. Elija el que le resulte más familiar. Me gustaría señalar algunas cosas que pueden ayudar a aclarar.
Table Data Gateway se usa principalmente para una sola tabla o vista. Contiene todas las selecciones, inserciones, actualizaciones y eliminaciones. Entonces 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 existe acoplamiento o no acoplamiento). Es simplemente una capa intermedia para transferir los datos entre los objetos y una base de datos, manteniéndolos independientes entre sí y del asignador mismo.
Por lo tanto, normalmente en un mapeador, ve métodos como insertar, actualizar, eliminar y en el gateway de datos de 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 que sus llamadas sean menos habladas ya que cada llamada puede ser costosa. Por lo tanto, generalmente se diseña un DTO que se puede serializar a través de un cable que puede transportar todos los datos al servidor para aplicar otras reglas comerciales o el procesamiento.
No estoy muy versado en el patrón de repositorio ya que no tuve la oportunidad de usarlo hasta ahora, pero buscaré respuestas de otros.
Data Mapper vs Table Data Gateway Para acortar la historia:
Al final, ambos actuarán como mediadores entre los objetos en memoria y la base de datos.