Almacenamiento en caché en la capa empresarial vs Almacenamiento en caché en la capa de datos

Siempre he trabajado en proyectos donde el almacenamiento en caché se realizó en DAL, básicamente, justo cuando está a punto de hacer la llamada a la base de datos, verifica si los datos ya están allí en la caché y, si lo está, simplemente no hace la llamada y en cambio devuelve esos datos.

Hace poco leí sobre el almacenamiento en caché en la capa empresarial, por lo que básicamente almacena en caché los objetos comerciales completos. Una ventaja que puedo ver de inmediato es que los tiempos de respuesta son mucho mejores.

¿Cuándo preferirías uno sobre el otro? ¿El almacenamiento en caché en Business Layer es una práctica común?

c# design design-patterns caching

— Emma
fuente

¿Es el rendimiento de sus aplicaciones tan crítico que el almacenamiento en caché en la capa empresarial es preferible a evitar la claridad de una llamada adicional a un repositorio o capa DAL?

— JDT

No, no lo es, y después de leer las respuestas, creo que me quedaría con el almacenamiento en caché en DAL. Aclamaciones.

— Emma

Debe considerar el almacenamiento en caché por encima de su capa empresarial y también pensar en escalar.

— AK_

Respuestas:

Esto es probablemente demasiado amplio para una respuesta definitiva. Personalmente, creo que una capa de acceso a datos es el mejor lugar para el almacenamiento en caché, simplemente porque se supone que es muy simple: los registros entran y salen, y eso es todo.

Una capa de negocio implementa muchas reglas adicionales de mayor complejidad, por lo que es mejor si no lo hace también tiene que gestionar las preocupaciones sobre la disponibilidad por objeto, además de las preocupaciones de consistencia de varios objetos de la misma clase (o incluso el mismo método) - que lo haría ser una violación flagrante del SRP.

(Por supuesto, solo llegué a esa idea después de que mis clases de servicio habían crecido a una complejidad inmanejable cuando intentaron hacer tanto el almacenamiento en caché como la configuración simultáneamente. No hay mejor maestro que experiencia, pero el precio seguro es elevado).

— Kilian Foth
fuente

¿Por qué el almacenamiento en caché debe ser complejo? Se puede hacer con AOP y un par de anotaciones. ¿Sigue siendo una violación de SRP? ¿Por qué no es cuando se hace en DAL? También IMHE Nunca vi clases de servicio "demasiado complejas" para ser almacenadas en caché; independientemente de su complejidad, un servicio puede verse como una caja negra y su resultado puede almacenarse en caché

— usuario1075613

El acceso a datos y las capas de persistencia / almacenamiento son lugares irresistiblemente naturales para el almacenamiento en caché. Están haciendo las E / S, haciéndolas prácticas, lugar fácil para insertar el almacenamiento en caché. Me atrevo a decir que casi todas las capas DAL o de persistencia tendrán, a medida que maduren, una función de almacenamiento en caché, si no está diseñada de esa manera desde el principio.

El problema es la intención . Las capas DAL y de persistencia se ocupan de construcciones de nivel relativamente bajo, por ejemplo, registros, tablas, filas y bloques. No ven el "negocio" o los objetos de la capa de aplicación, o tienen mucha información sobre cómo se utilizan en los niveles superiores. Cuando ven que se leen o escriben un puñado de filas o una docena de bloques, no está claro si representan. "La cuenta de Jones que estamos analizando actualmente" no se ve muy diferente de "algunos datos básicos de referencia de tasas impositivas que la aplicación necesita solo una vez, y a los que no volverá a referirse". En esta capa, los datos son datos son datos.

El almacenamiento en caché en la capa DAL / persistencia corre el riesgo de tener los datos de referencia de impuestos "fríos" allí, ocupando inútilmente 12.2MB de caché y desplazando parte de la información de la cuenta que, de hecho, se utilizará intensamente en solo un minuto. Incluso los mejores administradores de caché están lidiando con un escaso conocimiento de las estructuras y conexiones de datos de nivel superior, y con poca información sobre qué operaciones vendrán pronto, por lo que recurren a los algoritmos de estimación .

Por el contrario, el almacenamiento en caché de la aplicación o la capa empresarial no es tan bueno. Requiere insertar operaciones de administración de caché o sugerencias en medio de otra lógica comercial, lo que hace que el código comercial sea más complejo. Pero la compensación es: tener más conocimiento de cómo se estructuran los datos a nivel macro y qué operaciones están surgiendo, tiene una oportunidad mucho mejor de aproximar la eficiencia de almacenamiento en caché óptima ("clarividente" o "Bélády Min").

Si tiene sentido insertar la responsabilidad de administración de caché en el código de negocio / aplicación es una decisión sensata y variará según las aplicaciones. En muchos casos, aunque se sabe que las capas DAL / persistencia no lo harán "perfectamente bien", la compensación es que pueden hacer un trabajo bastante bueno, que lo hacen de una manera arquitectónicamente "limpia" y mucho más intensamente comprobable , y que la captura de bajo nivel evita aumentar la complejidad del código de negocio / aplicación.

Una menor complejidad fomenta una mayor corrección y confiabilidad, y un tiempo de comercialización más rápido. Eso a menudo se considera una gran compensación: un almacenamiento en caché menos perfecto, pero un código comercial más oportuno y de mejor calidad.

— Jonathan Eunice
fuente

Gracias por la respuesta. Después de leer las respuestas suyas y de los demás, creo que definitivamente no necesito almacenar en caché en la capa empresarial. Simplemente se agregará a la complejidad general del producto.

— Emma

Un problema con el modelo de "capas" es que los mecanismos de almacenamiento en caché eficientes a menudo necesitan usar información que no está disponible en una sola capa. ¿Qué pensaría, sin embargo, de que una capa empresarial transmita "pistas" a la capa de datos sobre su "plan" general? La capa de datos podría ignorar inicialmente la mayoría de estas sugerencias, pero si se encuentra un cuello de botella, se podría agregar cierta lógica que, cuando se dan ciertas sugerencias, alteraría las estrategias de almacenamiento en caché de una manera específica del negocio.

— supercat

Excelente punto, @supercat. Iba a mencionar una estrategia de insinuación / pragma, pero la respuesta ya era larga. Pero tienes toda la razón. Las sugerencias de la capa empresarial para las capas inferiores sobre cómo priorizar las memorias caché, o "qué fijar", son una forma bastante común / útil de obtener un almacenamiento en caché de nivel superior sin hacer que el código de la empresa lo haga todo, o quedar demasiado atrapado en la administración de su propio almacenamiento jerarquía.

— Jonathan Eunice

@JonathanEunice: Una cosa buena acerca de las sugerencias es que el código no tiene que hacer nada con ellos inicialmente. Una gran cantidad de sistemas tienen unos cuellos de botella evidentes que dominan su rendimiento, pero puede ser difícil predecir si cuáles van a ser bastante malo a la materia. La adición de una pequeña cantidad de la lógica de almacenamiento en caché fea en algunos puntos críticos puede ser mejor que un montón de esparcir la lógica de almacenamiento en caché en los lugares que realmente no importa.

— supercat

Exactamente. Especialmente si usted tiene "bastante bueno" el almacenamiento en caché de bajo nivel ya en la capa de persistencia / acceso. Es posible que necesite un poco de información añadido priorización para pasar de "bastante bueno" a "muy buena".

— Jonathan Eunice

El almacenamiento en caché en el DAL es sencillo y simple

Su DAL es la capa de acceso de datos central, lo que significa que cualquiera y todos los accesos de datos puede ser controlado a través de las clases allí. Dado que tanto la lectura y persistente que ocurre en esas capas es igualmente fácil de borrar o actualizar entradas de caché como suceden los cambios.

El almacenamiento en caché en el negocio es flexible

El almacenamiento en caché en el negocio brinda a los desarrolladores la flexibilidad para determinar si el uso concreto de un objeto se beneficiará del almacenamiento en caché. Dependiendo de la estructura de la aplicación, los servicios de fondo o los procesos automatizados pueden cambiar los datos que se almacenan en caché en otras partes. Con el almacenamiento en caché en el negocio, un desarrollador puede determinar si un determinado objeto comercial tendrá posibles datos obsoletos y obtendrá rendimiento, o si tendrá el estado más actualizado de un objeto comercial a expensas del rendimiento.

— JDT
fuente