¿Qué enfoque en el patrón DataMapper es mejor para tablas múltiples o unidas?

7

Normalmente, un asignador de datos asigna datos de una tabla en particular. (En teoría, debería estar comunicándose entre el Almacenamiento y un Objeto de Dominio, pero no es posible en mi caso, así que me estoy comunicando directamente con las tablas).

  

Table1Mappper > Tabla1

Pero si esa tabla requiere que los datos se unan de otra tabla, entonces está expandiendo el alcance de su asignador de datos, que se suponía que solo se debía asignar desde una tabla.

  

Table1Mapper > Tabla1: unión interna: Tabla2

¿No sería mejor si Table2 tuviera su propio mapper Table2Mapper para mapear sus datos?

Si piensa en Yes , entonces si desea mostrar una lista de registros de Table1Mapper y luego usar Table2Mapper para obtener los datos que se suponía que estaban unidos, se ejecutará una consulta en un bucle, que Tampoco es bueno.

¿Cuáles son tus ideas de esta manera?

¿Otra forma es cambiar tu asignador para manejar tablas secundarias?

class Table1Mapper {
    public main_table = 'table1';
    public sub_table1 = 'table2';
}

Creo que está bien, pero solo hasta que el alcance de todo el asignador trate con una entidad en particular en la aplicación. Por ejemplo, post y post_author . Pero si el alcance es diferente como post y gallery , lo anterior no dará un mapeador de datos ideal. Para ilustrar esto

class PostMapper {
     public table_name = 'tbl_post';
     public gallery_table_name = 'tbl_gallery';
}

No es correcto ¿verdad? Sin embargo, sin embargo, desearía obtener las galerías de una publicación en una consulta, ya que agregar una sobrecarga de consulta en un bucle no es un buen rendimiento de la solución.

¿Cuál crees que es la forma correcta de resolver esto en el patrón DataMapper / o cualquier otro patrón si tiene una mejor manera de manejar estos casos?

    
pregunta Starx 10.09.2015 - 11:36

1 respuesta

5

Por Data Mapper te refieres a uno descrito por Martin Fowler , ¿verdad? Es uno de los patrones de patrones de fuente de datos arquitectónicos. Otros son:

El asignador de datos difiere de otros patrones con respecto a la relación entre los objetos y las tablas. Tanto los patrones de la puerta de enlace de datos como el patrón de registro activo asumen que casi uno a uno se asigna de las tablas a los objetos.

Veamos un ejemplo:

table BANK_ACCOUNT
   ID

table BANK_ACCOUNT_BALANCE
   ID
   BANK_ACCOUNT_ID
   BALANCE_AMOUNT
   DATE

Los objetos de dominio son entonces:

class BankAccount {
    long id;
}

class BankAccountBalance {
    long id;
    long bankAccountId;
    Decimal balanceAmount;
    Date date;
}

Como se ve uno a uno mapeo entre clases y tablas. También hay dos puertas de enlace de datos de tabla / fila o registros activos, uno para cada tabla.

Por el contrario, Data Mapper permite indirection :

  

Una capa de Mappers (473) que mueve datos entre objetos y una base de datos mientras los mantiene independientes entre sí y con el mapeador en sí.

Entonces, cuando está utilizando el asignador de datos, sus objetos pueden diferir de las tablas de la base de datos. Usted es libre de introducir agregación, unirse a otras tablas, realizar operaciones aritméticas, introducir jerarquías de herencia. Por lo tanto, responda a su pregunta: es perfectamente correcto unir dos tablas en el asignador de datos siempre que el objeto de resultado sea un objeto de dominio válido.

En nuestro ejemplo podríamos tener:

class BankAccount {
    long id;
    Decimal latestBalance;
    Date latestBalanceDate;
}

como objeto de dominio devuelto por el asignador de datos único basado en ÚNICA y agregación.

Por lo tanto, Data Mapper es perfecto para representar un modelo de dominio no trivial. Si su modelo de dominio es bastante simple, podría considerar el uso de patrón de registro activo o puertas de enlace de datos.

Need for JOINs Data Mapper a veces (pero no debe) indica que la clase de dominio es demasiado compleja. Consulte Principio de responsabilidad única , Principio de segregación de interfaz .

En las clases de dominio de diseño impulsado por dominio (es decir, devueltas por el asignador de datos) toman la forma de entidades u objetos de valor. DDD book describe bastante bien de qué debería formar parte una entidad. Es posible que desee comprobar esto.

Además, DDD define Agregados (bastante bien descrito aquí ). A menudo se cargan juntos. Unir dos tablas podría sugerir que hay dos entidades en un solo agregado.

    
respondido por el Dawid Pytel 13.09.2015 - 15:42

Lea otras preguntas en las etiquetas