Se trata simplemente de la implementación de Table Data Gateway (TDG): crea una clase de TDG separada que contiene SQL para operaciones CRUD con una tabla concreta. Por lo tanto, sus modelos se comunican no directamente con una fuente de datos (por ejemplo, una base de datos), sino a través de esas abstractas: clases de TDG. Entonces, es solo un enfoque para hacer otro nivel de abstracción y es solo un envoltorio para comunicarse con la base de datos: obtener y modificar los datos. Las clases IMHO TDG no deben contener miembros, solo métodos. Aquí hay un buen esquema que visualiza el uso TDG pattern. Al usar el enfoque TDG, SQL debe moverse de las clases de modelo a las clases de origen de datos (TDG). Y todos los datos que recupero de DB a través de clases de TDG se almacenan en los miembros de mi modelo.¿Cómo difiere una implementación de Table Data Gateway de Active Record?
Ahora, ¿qué ocurre con la implementación de registros activos? Si fusionara el acceso a los datos y mi clase de modelo en una clase de modelo, ¿implementaría el registro activo? No pude encontrar una distinción clara o cómo esos patrones se ven en PHP y difieren entre sí.
A menudo, estoy teniendo una clase de base de datos singleton y luego una clase de modelo separada para cada tabla de base de datos. Cada clase de modelo tiene CRUD + varias operaciones personalizadas (conteo, prom y etc.). Algunas clases tienen miembros para resultados persistentes de CRUD o operaciones personalizadas, eso se hace según la necesidad. ¿Podría este enfoque ser identificado como registro activo? Además, si moviera SQL de mis clases modelo a las clases TDG, ¿se trataría de Table Data Gateway?
Gracias. ¿Qué tipos de métodos (y consultas SQL) podría tener al implementar TDG? No debería poner lógica de negocios, pero ¿qué se podría considerar una lógica de negocios? Por ejemplo, ¿puedo tener tales métodos (y consultas SQL) en clases TDG como selectAllRows, actualización por lotes (pasar una matriz de datos), seleccionar AllPersonsByLastName, countAll, SelectAvg y etc.? En mi humilde opinión, todos ellos deberían residir en la clase TDG. ¿Tiene algo de lógica de negocios cualquier cálculo adicional realizado a partir del conjunto de resultados de SQL derivado de la clase TDG? – Centurion
@Centurion a TDG puede contener todas las consultas SQL relacionadas con la tabla: inserciones, actualizaciones, selecciones (lógica de persistencia).No debe contener procesamiento de código de los resultados de la consulta (lógica comercial). Póngalo en un [Modelo de dominio] (http://martinfowler.com/eaaCatalog/domainModel.html) o en un [Módulo de tabla] (http://martinfowler.com/eaaCatalog/tableModule.html) – Gordon
Entendí:) pero tengo una pregunta más. Una clase de módulo de tabla se asigna a una tabla, por lo que en mi humilde opinión, tal clase de módulo de tabla podría considerarse como un modelo (cuando se habla en contexto de MVC). ¿Qué pasa con el modelo de dominio, qué debería considerarse un modelo? ¿Un grupo de clases que se usan para el controlador concreto? – Centurion