¿El almacenamiento en caché es un repositorio, dominio o problema de aplicación?

Question

Estoy tratando de averiguar qué capa debe ser responsable del trabajo de caché (insertar/eliminar) en un proyecto de diseño impulsado por dominio. El objetivo es mejorar el rendimiento de la aplicación web almacenando en caché todas las entidades que se recuperan del repositorio.

Mi solución es separada de la siguiente manera:

MyApp.Infrastracture 
MyApp.Repositories 
MyApp.Domain 
MyApp.WebApplication 

siento que ya que es sólo la aplicación Web que utiliza la memoria caché, entonces debería ser esta capa que la lógica de almacenamiento en caché debe ir? Sin embargo, esto no parece correcto ya que quiero mantener la aplicación web ligera y enfocada en servir páginas web.

también el almacenamiento en caché no es un concepto primer dominio de clase para que no tiene un paso natural en la capa de dominio.

¿Qué hacer?

Answer 1

Es una preocupación de todo lo anterior.

almacenamiento en caché es una de esas preocupaciones transversales que cada capa tiene que manejar de forma individual y la aplicación necesita para orquestar.

Answer 2

Estoy totalmente de acuerdo con Oded en que es una preocupación transversal, pero también debe ser transparente para el cliente de los elementos almacenados en caché.

Por ejemplo, los usuarios de su repositorio no deben preocuparse si un elemento se almacena en caché o no.

Me atrevería a decir que si el almacenamiento en caché es un aspecto importante de su solución, entonces debe quedar claro en el dominio, sin embargo, probablemente encontrará que realmente termina como parte de la infraestructura y se entrega (silenciosamente) a través de cualquier contenedor de IoC que use.

Answer 3

El almacenamiento en caché se puede distribuirse entre capas, a veces el almacenamiento en caché puede lograrse automáticamente en la capa de dominio si está utilizando un ORM como Nhibernate que soporta cachés de múltiples niveles. En las capas superiores podría basarse en los requisitos, por ejemplo, al cargar al usuario, el sistema carga cuáles son las funciones que el usuario puede hacer, y luego se puede almacenar en caché en el nivel de Aplicación. Entonces todo depende de la aplicación.

Answer 4

que anotó

El objetivo es mejorar el rendimiento de la aplicación Web mediante el almacenamiento cualquier entidad que se recuperan desde el repositorio.

Así que creo que debería implementarlo de forma transparente en su repositorio. El repositorio está destinado a ocultar los detalles de la persistencia del dominio, y si desea almacenar en caché objetos grandes para el rendimiento, entonces el dominio no debería ser más prudente. Su repositorio tendrá que ser bastante más inteligente, potencialmente rastreando múltiples copias del mismo objeto cuando los hilos paralelos soliciten objetos y los muten simultáneamente. O, si es posible, serialice el acceso a raíces agregadas individuales ya que representan límites de transacción.

Como @Oded señaló, el almacenamiento en caché realmente puede suceder en cualquier lugar, y es probable que se encuentre implementando en muchos lugares si el rendimiento es un problema, y ​​cada lugar puede hacerlo de manera diferente. Por ejemplo, puede almacenar en caché el resultado de ciertas consultas en su dominio, o puede almacenar en caché las respuestas completas de HTML.

La coordinación de capas cruzadas entra en acción porque las memorias caché pueden ser una abstracción bastante permeable. Si los objetos de su dominio están en la memoria caché, ¿cuándo deberían ser guardados? ¿Qué ocurre si un hilo está utilizando un objeto en caché y el otro no? ¿Qué sucede si está almacenando en caché los resultados de la consulta, pero los objetos subyacentes han cambiado desde entonces? Cuándo invalidar y cómo invalidar son preguntas difíciles, tanto desde la perspectiva de la infraestructura como desde la perspectiva del negocio. Las consultas antiguas no siempre son malas.