18

Ejemplo: Su base de datos tiene una vista SQL llamada "CustomerOrdersOnHold". Esta vista devuelve una mezcla filtrada de campos de datos de clientes y pedidos específicos. Necesita obtener datos de esta vista en su aplicación. ¿Cómo encaja el acceso a dicha vista en el patrón del repositorio? ¿Crearías un "CustomerOrdersOnHoldRepository"? ¿Es una vista de solo lectura como esta considerada una raíz agregada?¿Cómo encajan las vistas de base de datos de solo lectura en el patrón del repositorio?

Respuesta

24

yo preferiría que separa el repositorio de lectura, preferentemente incluso cambiar su nombre a Buscador o Reader, el repositorio está destinado para el uso del dominio no para consultar datos de solo lectura, puede consultar this article y this, que explica el uso del repositorio de formulario separado del Finder.

recomendaría también la separación del modelo de lectura de la arquitectura modelo de escritura y CQRSthere

Esta arquitectura permite separar el modelo de lectura a partir del modelo de escritura, incluso en términos de almacenamiento de datos y el uso de abastecimiento evento.

Para una solución intermedia puede utilizar algunos CQRS conceptos sin la complejidad de la separación de la base de datos con sólo separar repositorio de buscadores, lea este post

para una muestra de este tipo de soluciones (use la misma base de datos, pero buscadores separan repositorios de formularios) check this sample

+0

Creo que esta es la mejor respuesta. Este tipo de datos/objetos no tienen nada que ver con el dominio, y como Mohamed ha señalado, el término repositorio está asociado con agregados/dominio/transacciones, por lo que el uso de este término podría ser engañoso. CQRS tiene como objetivo resolver este problema exacto. Hace un tiempo hice una pregunta similar: http://stackoverflow.com/questions/2098112/ddd-how-to-implement-performant-repositories-for-searching –

+0

Excelente respuesta debido a los excelentes enlaces. Esto me ayudó a ver mi código desde una perspectiva diferente y más clara. –

+0

Si tiene un Buscador, ¿cómo llama al "Ahorrador"? ¿Repositorio? Pero entonces, un repositorio debería poder acceder a los datos AKA "consulta" ... ¿cómo abordar esto? – JorgeeFG

0

Creo que está bien tener un repositorio separado como "CustomerOrdersOnHoldRepository". La interfaz del repositorio reflejará el hecho de que los objetos son de solo lectura (al no definir el método Save/Add/MakePersistent).

De How to write a repository:

... Pero hay otra estrategia que me gusta bastante: múltiple repositorios. En nuestro ejemplo de pedido no hay ninguna razón por la que podamos tener dos repositorios: AllOrders y SurchargedOrders. AllOrders representa una lista que contiene cada orden individual en el sistema, SurchargedOrders representa un subconjunto de ella.

No llamaría al objeto devuelto una raíz de Aggrgate. Los agregados son por consistencia, intercambio de datos y ciclos de vida. Tus objetos no tienen ninguno de estos. Parece que tampoco se pueden clasificar como objetos de valor ('característica o atributo'). Son solo clases independientes.

+0

Me estaba inclinando a dar a la vista su propio repositorio, sin embargo, tengo entendido que los repositorios operan solamente en raíces agregadas (http://thinkddd.com/glossary/aggregate-root/). –

+0

Esta regla trata de evitar el acceso directo a las partes internas del agregado. No tiene estas partes internas, al igual que no tiene ninguna invariante y ciclo de vida. Está bien devolver estos objetos desde el repositorio. Llámelos Aggregate Roots si lo desea, pero eso puede ser un poco engañoso. – Dmitry

0

Sus datos de solo lectura se considerarían objetos de valor en el mundo de DDD.

Normalmente coloco métodos de acceso para objetos de valor en repositorios existentes hasta el momento en que tiene sentido crear un repositorio separado. Es similar a un método que podría producir una lista estática de los estados para ser utilizado en un formulario de dirección:

IAddressRepository 
{ 
    Address GetAddress(string addressID); 

    List<string> GetStates(string country); 
} 
+0

Entonces, en su escenario, si tengo un CustomerRepository o un OrderRepository ¿agregaría un método a uno de estos repositorios? es decir 'ICustomerRepository.GetCustomerOrdersOnHold (args)' o 'IOrderRepository.GetCustomerOrdersOnHold (args)'? –

Cuestiones relacionadas