La memorizzazione nella cache appartiene a una classe di repository?

È possibile utilizzare un design adeguato per ottenere il meglio da entrambi i mondi. Potresti usare il modello decoratore come suggerito da Vincent.

In questo modello hai CachingRepository che implementa l'interfaccia del tuo repository e ha un'istanza del repository a cui delega le chiamate (quando c'è un errore di cache). Questo design separa le preoccupazioni di cache e le entità di recupero, ma invisibilmente al client di Repository .

Lo psuedocode di CachingRepository sarebbe:

getFoo(id): Foo
  if cache contains id
    return cached Foo
  else
    call getFoo on delegate
    store result of getFoo in cache
    return result

Nella tua radice composizione creerai un'istanza di CachingRepository con DbRepository come suo delegato

Repository repo = new CachingRepository(new DbRepository(...));

Penso che in genere dipenda dalla natura dei dati memorizzati nella cache e dallo scopo. Alcune cache dovrebbero trovarsi nel repository. Queste sono le cache progettate per fornire accesso accelerato a valori coerenti e accurati. Esempi di basso livello sarebbero cache del disco, piani di query DB, anche valori da una cache Redis che sono pensati per essere un rapido riflesso dei valori attuali, attuali.

Le cache delle applicazioni sono bestie diverse e non devono vivere nel repository attuale o essere condivise. Un esempio potrebbe essere un elenco di codici ticker conservati nel server Web (o persino nella memoria locale del browser) validi per un giorno.

I prezzi dei ticker in tempo reale possono essere da qualche parte nel mezzo - persistenti in un repository "corretto" ma allo stesso tempo resi disponibili alle applicazioni in un modo più veloce, se meno flessibile o coerente (di nuovo, come una copia in Redis o simile).

Penso che il riassunto sia che hai bisogno di tecniche diverse per circostanze diverse, da qui la tua schiena & avanti cercando di arrivare all '"unica vera risposta" che non c'è.

Si può separare in modo che il database o il "repository" non abbiano idea che i dati vengano memorizzati nella cache. Questa è una soluzione pulita e può essere implementata secondo necessità attraverso i metodi di query del repository. Come @Vincent suggerisce che questo è un tipo di decoratore di pattern. Finga IQuery è il comando repository per ottenere i dati (TOut). (TIn) può essere una sorta di oggetto che rappresenta un criterio o parametri utilizzati dal comando query.

Se i dati non sono nella cache, usiamo il repository per recuperarlo.

public class QueryCaching<TIn, TOut> : IQuery<TIn, TOut>
    {
        private readonly ICache _cache;
        private readonly IQuery<TIn, TOut> _command;
        private readonly string _key;

        public QueryCaching(string key, ICache cache, IQuery<TIn, TOut> command)
        {
            _command = command;
            _key = key;
            _cache = cache;
        }

        public TOut Execute(TIn input)
        {
            TOut obj;
            if (_cache.Get(_key, out obj))
            {
                Debug.WriteLine(string.Format("Cache hit for key {0}", _key));
                return obj;
            }

            Debug.WriteLine(string.Format("Cache miss for key {0}", _key));
            obj = _command.Execute(input);
            _cache.Set(_key, obj);

            return obj;
        }
    }