Stiamo usando il modello di repository giusto?

Stiamo usando un gruppo di classi separate con suffisso -repositoryper recuperare i dati dal database; per ogni tabella il proprio repository.

Abbiamo ad esempio una customerrepositoryclasse che ha tutti i tipi di metodi per recuperare i clienti e una vacancyrepositoryche ha tutti i tipi di metodi per recuperare i posti vacanti.

Ho due domande su questo modo di fare le cose:

Che ne dite di ottenere dati che si estendono su più tabelle? Ad esempio, ho una schermata che mostra tutti i clienti che non hanno ancora creato un posto vacante. Un customerrepositorymetodo di utilizzo dal vacancyrespositoryo entrambi i repository restituiscono risultati? Esiste una classe superiore nella gerarchia (chiamiamola a dataservice) che ottiene i risultati da entrambi i repository e li combina in 1 risultato?
quanta logica può gestire un simile repository?
Penso che sia OK implementare il 'where active == true' in un repository per recuperare solo i record attivi, o anche quella semplice logica dovrebbe essere gestita da una classe superiore nella gerarchia (chiamiamola a dataservice)?

L'esempio che stavo incontrando ora è questo:

Abbiamo un elenco di domande, che contiene una o più domande.
La domanda può avere un risultato, che è contenuto in una tabella separata.
Pertanto, quando si desidera recuperare il risultato totale dell'elenco delle domande, è necessario combinare i dati dalla questionlisttabella, dalla tabella delle domande e dalla questionstatustabella.

In questo momento abbiamo 3 diversi repository per queste tabelle.

Se chiedessi questionlistrepositoryqual è il risultato totale per l'elenco numero 12, dovrebbe ottenere i dati da altri due repository e quindi avere qualche logica in esso, è permesso?

O c'è un questionlistdataservicechissà quali repository usare?

Ancora una cosa: i nostri repository possono risultare in IQueryablemodo che un servizio di chiamata possa facilmente combinare i risultati, ma che ne dici di quando non è così, non credo sia una buona idea recuperare tutto il contenuto di tutte e tre le tabelle dal Banca dati.

c# design design-patterns repository

— Michel
fonte

In genere in più accessi alla tabella, la tabella dominante è determinata dalla tabella del record che deve esistere prima che la query la recuperi. In LEFT OUTER JOIN, quella sarebbe la prima tabella menzionata e in RIGHT OUTER JOIN, sarebbe la seconda.

— Neil,

Il repository restituisce oggetti di dominio e si basa su livelli di mappatura. Per un dominio molto semplice, gli oggetti del dominio e le tabelle del database possono essere molto simili.

Se il tuo repository restituisce sempre la rappresentazione esatta della tua struttura di dati, allora potrebbe effettivamente essere Table Data Gateway aka DAO (Data Access Object).

Esempio: il database contiene tabelle per persona e indirizzo. Nel tuo indirizzo di dominio l'indirizzo non è un'entità propria, è solo una proprietà di Person. In questo caso non avresti PersonRepository e AddressRepository. Hai solo PersonRepository. Il dominio non dovrebbe preoccuparsi della persistenza dei dati del dominio. Tali responsabilità si trovano in un livello dietro il repository.

Dal tuo esempio sembrerebbe che tu abbia effettivamente DAO e che tu li abbia appena nominati Repository.

— simoraman
fonte

Quindi, quando creo un repository, posso anche avere un gateway dati Table un livello più profondo, ei nostri repository sono in realtà TDG.

— Michel,

Potresti, ma soppesare il costo e i benefici. Non essere vittima di bullismo nel mantenere separati DAO e Repository dal principio di "stratificazione" del codice. Fai ciò che è più leggibile in questo caso. La separazione e il risultante livello di astrazione possono essere utili se i repository tendono a fare molta ricombinazione dei dati nei DAO.

— Mihai Danila,