2011-05-05 11 views
5

Digamos que mi capa de negocio actualmente contiene un montón de DTO y clases de servicio separadas para comunicarse con el repositorio de datos.¿Qué capa funciona como: el almacenamiento en caché y el registro pertenecen?

Ejemplo:

class PersonService 
{ 
    IPersonRepository _personRepository; 
    ILogging _logger; 
    ICacheStorage _cache; 
    // Constructor here to create concrete objects. 

    public Person GetPersonById(int Id) 
    { 
     // error logging and caching here??? 
    } 
} 

¿Tiene sentido para iniciar la sesión y la memoria caché en esta capa? ¿O tendría más sentido para una capa de servicio de aplicaciones manejar estas preocupaciones? O tal vez algo más en total?

Respuesta

3

El almacenamiento en caché puede o debe implementarse siempre que sea posible. Además, el almacenamiento en caché debe ser transparente, por lo que cualquier persona que lo use no debe saber que se está usando realmente. La mayoría de las veces es lógico ponerlo dentro de una capa de acceso a datos, pero a veces es lógico y posible ponerlo en la capa de negocios también.

El registro es IMO algo, que no pertenece a ninguna capa. Debería ser para toda la aplicación con un punto de acceso.

+0

+1. Use el almacenamiento en caché donde sea que tenga sentido. Podría usarlo dentro del DAL para que sea más fácil su propia vida; y el BL podría almacenar en caché las cosas que obtiene del DAL para ahorrar en llamadas a través del límite BL \ DAL. Esto último también tiene sentido si el BL habla con más de una implementación DA (como un servicio). –

+0

De acuerdo: la tala es una preocupación transversal y puede ir a cualquier parte. –

1

Yo diría que el almacenamiento en caché es un detalle de implementación de la recuperación de datos. En lo que respecta a PersonService, tiene un PersonRepository que puede usar para obtener sus datos. El hecho de que pueda estar en la memoria o en la base de datos es un detalle del que no debe preocuparse. Por lo tanto, digo que el almacenamiento en caché baja en la capa de acceso a datos.

En cuanto al registro, puede ser en cualquier lugar y en cualquier lugar. Realmente no hay un lugar "incorrecto" para iniciar sesión. (Por eso es visto típicamente como una "preocupación transversal" y por qué las personas usarán AOP para iniciar sesión ver discusión aquí: Advice on AOP with C#)

+0

¿Cómo es posible que la capa de acceso a datos sepa cuándo caducar la caché? ¿Esto no es parte de la lógica del dominio? – Henrik

+0

@Henrik: ¿Lo es? Yo diría que el tiempo de caducidad sigue siendo un detalle del mecanismo de almacenamiento en la aplicación, no del lado comercial de las cosas. – BFree

+0

Depende. El BL de la aplicación podría dictar cuándo los datos están "desactualizados" y deben actualizarse; alternativamente, si los datos con los que está integrando pertenecen a un sistema externo (o sistemas), el punto de decisión podría ser otro. –

1

El registro y el seguimiento se implementan como clases de utilidad y se invocan en la mayoría o en todos los niveles de su arquitectura. La implementación del almacenamiento en caché varía según el nivel y el sistema. Puede tener diferentes tipos de caché y estrategias de almacenamiento en caché, en diferentes niveles, y depende completamente del sistema en cuestión. Puede usar una combinación de almacenamiento en caché distribuido y en proceso para lograr el rendimiento deseado y las características de coherencia.

Cuestiones relacionadas