No estoy seguro de dónde debo implementar el almacenamiento en caché en mi patrón de repositorio.Patrón de repositorio: almacenamiento en caché
¿Debo implementarlo en la lógica de servicio o en el repositorio?
interfaz gráfica de usuario -> BusinessLogic (Servicios) -> dataAccess (repositorios)
que se ocuparía en la capa de acceso al repositorio/datos. El razonamiento se debe a que no depende de la capa empresarial de dónde obtener los datos, ese es el trabajo del repositorio. El repositorio decidirá de dónde obtener los datos, la caché (si no es demasiado antigua) o de la fuente de datos en vivo en función de las circunstancias de la lógica de acceso a datos.
Es una cuestión de acceso a los datos más que un problema de lógica empresarial.
Es una buena idea no poner la lógica de almacenamiento en caché directamente en su repositorio, ya que eso viola el Principio de Responsabilidad Individual (SRP) y la Separación de Preocupaciones. SRP esencialmente establece que sus clases solo deberían tener un motivo para cambiar. Si combina las preocupaciones sobre el acceso a los datos y la política de caché en la misma clase, entonces, si alguna de estas necesidades cambia, deberá tocar la clase. También es probable que descubra que está violando el principio DRY, ya que es fácil tener la lógica de almacenamiento en caché extendida entre muchos métodos de repositorio diferentes, y si alguno de ellos necesita cambiar, terminará teniendo que cambiar muchos métodos.
El mejor enfoque es utilizar el patrón Proxy o Estrategia para aplicar la lógica de almacenamiento en caché en un tipo separado, por ejemplo, un repositorio caché, que utiliza el repositorio db-centric actual según sea necesario cuando el caché está vacío. He escrito dos artículos que demuestran cómo implementar esto utilizando/C# .NET, que se encuentra en mi blog, aquí:
Si prefiere vídeo, también describo el patrón en el patrón de diseño Proxy en Pluralsight, aquí:
Más sobre el patrón aquí: http://deviq.com/repository-pattern/ – ssmith
Estoy de acuerdo con su enfoque. Las clases de lógica de negocios heredadas siguen usando el repositorio no almacenado en caché y los nuevos servicios lógicos de negocios podrían usar el nuevo. Tiene menos impacto en la lógica existente – equintas
esta debería ser la respuesta correcta – Allie
¡Gracias por la respuesta! Creo que también es mejor para la carga lenta de implementación. – Beni