Non sono sicuro di dove implementare la memorizzazione nella cache nel modello del repository.Pattern deposito - Memorizzazione nella cache
Devo implementarlo nella logica di servizio o nel repository?
GUI -> BusinessLogic (Servizi) -> DataAccess (repository)
vorrei gestirlo nel livello di accesso repository/dati. Il ragionamento è dovuto al fatto che non dipende dal livello aziendale su cui ottenere i dati, cioè dal lavoro del repository. Il repository deciderà quindi da dove ottenere i dati, la cache (se non è troppo vecchia) o dall'origine dati live in base alle circostanze della logica di accesso ai dati.
È un problema di accesso ai dati più che un problema di logica aziendale.
È una buona idea non inserire la logica di memorizzazione nella cache direttamente nel repository, in quanto ciò viola il Single Responsibility Principle (SRP) e Separation of Concerns. SRP afferma essenzialmente che le tue classi dovrebbero avere solo una ragione per cambiare. Se si confondono i dubbi sull'accesso ai dati e sulla politica di memorizzazione nella cache nella stessa classe, se uno di questi deve cambiare è necessario toccare la classe. Probabilmente scoprirai anche che stai violando il principio di DRY, dal momento che è facile avere una logica di caching diffusa tra molti diversi metodi di repository, e se qualcuno di questi ha bisogno di cambiare, si finisce per dover cambiare molti metodi.
L'approccio migliore consiste nell'utilizzare il modello Proxy o Strategia per applicare la logica di memorizzazione nella cache in un tipo distinto, ad esempio un CachedRepository, che quindi utilizza il repository db-centric effettivo quando necessario quando la cache è vuota. Ho scritto due articoli che dimostrano come implementare questo utilizzando .NET/C#, che si trova sul mio blog, qui:
Se si preferisce il video, ho anche descrivere il modello nel design pattern Proxy Pluralsight, qui:
Maggiori informazioni sul modello qui: http://deviq.com/repository-pattern/ – ssmith
Sono d'accordo con te approccio. Le classi di logica aziendale legacy continuano a utilizzare il repository non memorizzato nella cache e i nuovi servizi di logica aziendale potrebbero utilizzare quello nuovo. Hai meno impatto sulla logica esistente – equintas
questa dovrebbe essere la risposta corretta – Allie
Grazie per la risposta! Penso che sia anche meglio per il caricamento lazy di implementazione. – Beni