php - resueltos - ¿Por qué el patrón de registro activo no funciona con modelos de dominio enriquecido?
modelo de dominio herencia (2)
Lo que está tratando de decir es que los modelos de dominio más complejos suelen ser más que solo "datos de una tabla". Estos modelos más complejos de los que habla Fowler son modelos que obtienen datos de diferentes tablas, vistas o incluso otras fuentes.
El patrón Active Record no es muy adecuado para este propósito, y el patrón DataMapper combinado con solo las clases de modelo (que contienen solo la lógica comercial y no se comunican con la capa de acceso a datos) es probablemente más adecuado en situaciones como estas.
El patrón de registro activo falla aquí, porque se asigna más o menos directamente a una tabla en la base de datos.
No sé la definición exacta del patrón, así que por favor corrígeme si estoy equivocado.
Estoy leyendo el capítulo de patrones arquitectónicos de POEAA, y Fowler dice que "a medida que la lógica de dominio se vuelve más complicada y comienzas a avanzar hacia un rico modelo de dominio (116), el enfoque simple de un registro activo (160) comienza a descomponerse La combinación uno a uno de las clases de dominio con las tablas comienza a fallar a medida que factoriza la lógica de dominio en clases más pequeñas. Las bases de datos relacionales no manejan la herencia, por lo que resulta difícil usar estrategias [Gang of Four] y otros patrones ordenados OO A medida que la lógica de dominio se pone enérgica, quiere poder probarla sin tener que hablar con la base de datos todo el tiempo ".
Realmente no entendí esto. Por "coincidencia uno a uno de las clases de dominio con las tablas", ¿quiere decir eso solo para las clases donde no hay asociaciones o una jerarquía de herencia de tabla única?
¿Y por qué la lógica del dominio de factoring en clases más pequeñas hace que el patrón falle?
No, creo que él está hablando de la lógica del dominio. Con el registro activo, el objeto lleva datos y comportamiento. Entonces esa es una coincidencia uno a uno. Si comienza a separar datos / comportamiento, como en el patrón Data Mapper, se convierte en uno-a-muchos. Tengo la impresión de que a veces tienes que leer ese libro como una tontería académica para entender lo que quiere decir. :-)