almacenamiento en caché Código Ubicación en un Domain Driven Design

Question

En una aplicación que ha seguido un Domain Driven Design donde tiene los siguientes tipos de conceptos

1. Un repositorio que se ocupa de la base de datos Access
2. Un servicio de aplicación que coordina las interacciones entre entidades y objetos de valor, etc.

donde, en general, ¿pondría el código de almacenamiento en caché para elimentar una costosa llamada a la base de datos?

He visto bases de código que simplemente almacenan en caché por todas partes y es difícil controlar el uso de memoria y es difícil proporcionar directrices a otros desarrolladores.

Por favor, comprenda que sé que solo debería almacenar datos en caché cuando lo necesite, solo estoy haciendo una pregunta general.

Answer 1

Lo maravilloso de los repositorios abstractos es que puede usar el Decorator pattern para implementar problemas tan generales como el almacenamiento en caché.

A modo de ejemplo, dada una interfaz IMyRepository, se puede crear un MyCachingRepository como este pseudo código:

public class MyCachingRepository : IMyRepository 
{ 
    private readonly IMyRepository repository; 

    public MyCachingRepository(IMyRepository repository) 
    { 
     if(repository == null) 
     { 
      throw new ArgumentNullException("repository"); 
     } 

     this.repository = repository; 
    } 

    public Foo SelectFoo(int id) 
    {  
     Foo foo = ... // attempt to get foo from cache 

     if // foo is not it cache 
     { 
      foo = this.repository.SelectFoo(id); 
      // save foo in cache 
     } 
     return foo; 
    } 
} 

En este ejemplo, se define por getFoo IMyRepository. Observe cómo el Repositorio decorado solo se invoca si el caché no encuentra el elemento.

Esto sigue al Single Resposibility Principle porque la implementación del almacenamiento en caché real puede concentrarse en recuperar y guardar datos, mientras que el decorador de caché puede concentrarse en el almacenamiento en caché. Esto le permite variar los dos independientemente el uno del otro.

En nuestro proyecto actual usamos este enfoque, y lo que es más agradable es que podríamos hacerlo como una ocurrencia tardía sin siquiera tocar los repositorios originales. Esto está en el espíritu del Open/Closed Principle.

Answer 2

Lo pondría en los repositorios. Los repositorios deben estar definidos por un contrato, y el uso de un caché debe ocultarse detrás de ese contrato, por lo que es transparente para el consumidor del repositorio.