Cosa dovrebbe fare davvero un repository?


15

Ho ascoltato molto il modello di repository, ma non capivo cosa dovesse fare davvero un repository. Quando dico "cosa dovrebbe fare davvero un repository", mi preoccupo principalmente di quali metodi dovrebbe fornire. Ad esempio, un repository dovrebbe davvero fornire metodi CRUD o dovrebbe fornire un diverso tipo di metodo?

Voglio dire, i repository dovrebbero contenere la logica aziendale o dovrebbero semplicemente contenere la logica per comunicare con l'archivio dati e gestire le entità da salvare o caricare?

Inoltre ho sentito che i repository sono unità di persistenza per gli aggregati. Ma come va? Non riesco a capire come funziona in pratica. Ho pensato che avremmo dovuto avere solo un'interfaccia IRepositoryche contiene i metodi CRUD, e quindi per qualsiasi entità l'implementazione avrebbe semplicemente contenuto la logica per salvare e recuperare tale tipo dall'archivio dati.


4
"i repository dovrebbero contenere una logica aziendale" - no.
ozz

1
Ecco la mia risposta a una domanda correlata su SO
Eric King,

2
Penso che tu stia ottenendo preso sulla parola "dovrebbe" - repository è un modello specifico, si parla come se ci fosse un modo un pronti contro termine deve essere fatto che è il modo migliore per fare un pronti contro termine; questo è un malinteso in quanto esiste solo un modo per fare un repository, qualsiasi altra cosa non sarebbe un repository. In quanto tale, il modello di pronti contro termine presenta punti di forza e di debolezza, ma non esistono approcci multipli a un pronti contro termine. Ci sono però diversi modi per interagire con i dati, di cui un repo è una sola. Leggi qui per altri approcci di interazione dei dati
Jimmy Hoffa,

Risposte:


13

Bene, puoi vedere un buon esempio in Spring Data Framework che si basa sul concetto di repository.

Lì vedrai che i repository si occupano solo dell'archivio dati e raramente contengono alcuna logica aziendale (questo è riservato per il livello di servizio). Quindi, ad esempio, dai un'occhiata al loro design e vedrai che hanno un'interfaccia CRUDRepository che espone metodi per creare, distruggere e recuperare entità (tra le altre cose). C'è anche un PagingAndSortingRepository che aggiunge funzionalità extra proprio per questo, risultati di ordinamento e paging, ecc. Ecc.

Quindi, questo framework è forse un buon posto per studiare un buon design del repository.

Per quanto ne so, molti dei concetti implementati dal Spring Data Framework provengono da un grande libro intitolato Domain-Driven Design: Tackling Complexity in the Heart of Software , il libro ha un'intera sezione dedicata al design del repository.

Puoi prendere in considerazione l'idea di ottenerne una copia.

Un piccolo estratto del libro spiega:

Il modello REPOSITORY è un semplice framework concettuale per incapsulare quelle soluzioni e riportare il focus del nostro modello.

Un REPOSITORY rappresenta tutti gli oggetti di un certo tipo come un insieme concettuale (solitamente emulato). Funziona come una raccolta, tranne con una capacità di query più elaborata. Vengono aggiunti e rimossi oggetti del tipo appropriato e il macchinario dietro il REPOSITORY li inserisce o li elimina dal database. Questa definizione raccoglie un insieme coerente di responsabilità per fornire l'accesso alle radici di AGGREGATES dal ciclo di vita iniziale fino alla fine.

I client richiedono oggetti dal REPOSITORY utilizzando metodi di query che selezionano gli oggetti in base a criteri specificati dal client, in genere il valore di determinati attributi. Il REPOSITORY recupera l'oggetto richiesto, incapsulando il meccanismo di query del database e mappatura dei metadati. I REPOSITORI possono implementare una varietà di query che selezionano gli oggetti in base ai criteri richiesti dal cliente. Possono anche restituire informazioni di riepilogo, ad esempio un conteggio di quante istanze soddisfano alcuni criteri. Possono persino restituire calcoli di riepilogo, come il totale su tutti gli oggetti corrispondenti di alcuni attributi numerici.

Un REPOSITORY solleva un enorme onere dal cliente, che ora può parlare con un'interfaccia semplice e che rivela l'intenzione e chiedere ciò di cui ha bisogno in termini di modello. Per supportare tutto ciò è necessaria una complessa infrastruttura tecnica, ma l'interfaccia è semplice e concettualmente connessa al modello di dominio.

Perciò:

Per ogni tipo di oggetto che necessita di accesso globale, creare un oggetto in grado di fornire l'illusione di una raccolta in memoria di tutti gli oggetti di quel tipo. Configurare l'accesso tramite una nota interfaccia globale.

Fornire metodi per aggiungere e rimuovere oggetti, che incapsuleranno l'inserimento o la rimozione effettiva dei dati nell'archivio dati. Fornire metodi che selezionano gli oggetti in base ad alcuni criteri e restituiscono oggetti o raccolte di oggetti completamente istanziati i cui valori di attributo soddisfano i criteri, incapsulando così l'effettiva tecnologia di archiviazione e query. Fornire i repository solo per le radici AGGREGATE che necessitano effettivamente dell'accesso diretto. Mantieni il client focalizzato sul modello, delegando tutto l'archiviazione degli oggetti e l'accesso ai REPOSITORI.


4

Non dovrebbe fornire né un'interfaccia CRUD diretta né una logica aziendale. Media tra logica aziendale e database. L'interfaccia dovrebbe essere in termini di logica aziendale ma non eseguire la stessa logica aziendale, più come una primitiva di logica aziendale. Ad esempio, dire che avresti creato un sistema di posta elettronica, hai utenti e messaggi. Il tuo repository fornirebbe operazioni CRUD di base per utenti e messaggi ma fornirà anche visualizzazioni filtrate di messaggi come GetUsersNewMessages (utente) o GetSearchedMessages (utente, searchTerms).

L'idea è che il repository nasconda il modo in cui viene implementata la memoria e fornisce un'interfaccia pulita che consente un accesso rapido e flessibile ai dati. Mantenere le operazioni ad alto livello su ciò che dovrebbe accadere piuttosto che sul modo in cui si ha una maggiore flessibilità per implementarle nel modo migliore per il backing store sottostante.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.