Come implementare il mio repository (DDD) in C# per gestire più chiamate per la stessa radice di aggregazione

Question

Quale classe nel mio progetto dovrebbe essere responsabile di tenere traccia di quali Radar aggregati sono già stati creati in modo da non creare due istanze per stessa entità Il mio repository dovrebbe tenere un elenco di tutti gli aggregati che ha creato? Se sì, come faccio? Uso un repository singleton (non mi sembra corretto)? Ci sarebbero altre opzioni per incapsulare questo "caching" da qualche altra parte è un'altra classe? Come sarebbe questa classe e in quale modello sarebbe adatta?

Non sto usando un mappatore O/R, quindi se c'è una tecnologia là fuori che la gestisce, avrei bisogno di sapere come funziona (come in quale modello utilizza) per essere in grado di usare si

Grazie!

Answer 1

Credo che tu stia pensando al modello Identity Map, as described by Martin Fowler.

Nella sua descrizione completa del modello (nel suo libro), Fowler discute problemi di implementazione per le entità di lettura/scrittura (quelle che partecipano alle transazioni) e di sola lettura (dati di riferimento, che idealmente dovrebbero essere letti solo una volta e successivamente memorizzato nella cache).

Suggerisco di ottenere il suo eccellente libro, ma l'estratto che descrive questo modello è leggibile su Google Libri (cercare "mappa di identità fowler").

In sostanza, una mappa di identità è un oggetto che memorizza, ad esempio in una tabella hash, gli oggetti entità caricati dal database. La mappa stessa viene memorizzata nel contesto della sessione corrente (richiesta), preferibilmente in un'unità di lavoro (per le entità di lettura/scrittura). Per le entità di sola lettura, la mappa non deve necessariamente essere legata alla sessione e può essere archiviata nel contesto del processo (stato globale).

Answer 2

Ritengo caching per essere qualcosa che accade a livello di servizio, piuttosto che in un repository. I repository dovrebbero essere "stupidi" e fare semplicemente operazioni CRUD di base. I servizi possono essere abbastanza intelligenti da funzionare con il caching secondo necessità (che è probabilmente più una regola aziendale che una regola di accesso ai dati di basso livello).

Per dirla semplicemente, non lascio alcun repository utilizza il codice direttamente - solo i servizi possono farlo. Quindi tutto il resto consuma i servizi rilevanti come interfacce. Questo ti dà un bel wrapper per mettere in logica, cache, ecc.

Answer 3

Direi che se questo "caching" è gestito in un posto diverso dal repository, allora stai lasciando uscire le preoccupazioni.

Il repository è la vostra collezione di oggetti. Nessun codice che consuma il repository dovrebbe decidere se recuperare l'oggetto dal repository o da qualche altra parte.

Singleton suona come la vita sbagliata; probabilmente dovrebbe essere per richiesta. È facile da gestire se si utilizza un contenitore IoC/DI.

Sembra che il fatto di considerare più chiamate per le stesse evidenze aggregate sia un problema di architettura/progettazione. Sarei interessato a sentire un esempio di cosa potrebbero essere queste prime e seconde chiamate e perché richiedono la stessa esatta istanza del tuo AR.