¿Cómo encajan las vistas de bases de datos de solo lectura en el patrón del repositorio?

Question

Ejemplo: su base de datos tiene una vista SQL llamada "CustomerOrderSersonhold". Esta vista devuelve una mezcla filtrada de campos de datos específicos de clientes y pedidos. Debe obtener datos de esta vista en su aplicación. ¿Cómo encaja el acceso a tal vista en el patrón de repositorio? ¿Crearía un "CustomerOrdersonholdRepository"? ¿Se considera una visión de solo lectura como esta una raíz agregada?

Answer 1

Preferiría separar el repositorio de lectura, preferiblemente incluso cambiar su nombre al buscador o lector, el repositorio está destinado al uso del dominio, no para consultar datos de solo lectura, puede consultar a Este artículo y este lo que explica el uso del repositorio de formulario separado de Finder.

Recomendaría también la separación del modelo de lectura de la arquitectura del modelo de escritura CQRS y allá

Esta arquitectura le permite separar el modelo de lectura del modelo de escritura incluso en términos de almacenamiento de datos y el uso del abastecimiento de eventos.

Para una solución media, puede utilizar algunos conceptos CQRS sin la complejidad de separar la base de datos simplemente separando el repositorio de los buscadores, lea esto correo

Para una muestra de este tipo de solución (use la misma base de datos pero separe los repositorios de formulario de los buscadores) verifique esta muestra

Answer 2

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

Por lo general, 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 devolver una lista estática de estados que se utilizarán en un formulario de dirección:

IAddressRepository
{
  Address GetAddress(string addressID);

  List<string> GetStates(string country);
}

Answer 3

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

De Cómo escribir un repositorio:

... Pero hay otra estrategia que me gustan: múltiples repositorios. En nuestro ejemplo de pedido, no hay razón para que podamos tener dos repositorios: Alfals y Recargedorders. Allorders representan una lista que contiene cada pedido en el sistema, los medios de referencia representan un subconjunto de la misma.

No llamaría a un objeto devuelto como una raíz de agresión. Los agregados son para la consistencia, el intercambio de datos y los ciclos de vida. Tus objetos no tienen ninguno de estos. Parece que tampoco pueden clasificarse como objetos de valor ('característica o atributo'). Son solo clases independientes.