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.
fuente
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.
fuente
Data Mapper vs Table Data Gateway Para resumir una larga historia:
Al final, ambos actuarán como mediadores entre los objetos en memoria y la base de datos.
fuente
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.
fuente
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.
fuente