È meglio avere un repository per modello (potrebbe trattarsi di una classe che rappresenta una tabella dal database) o dovrebbe avere solo un grande repository per tutti i metodi di accesso ai dati?
Ho fatto il secondo approccio e l'ho trovato sfuggire di mano, ma forse anche una via di mezzo è una soluzione.
Perché i repository sono diversi dalle altre classi?
Una classe dovrebbe avere un'unica responsabilità, un solo motivo per cambiare. Se si dispone di un insieme di origini dati correlate che sono (necessariamente) strettamente accoppiate, allora può avere senso disporre di un unico repository per gestirle tutte. Se hai alcune tabelle non correlate, probabilmente è meglio avere un singolo repository per tabella.
Implementare i repository "dal libro" tipicamente significa crearne uno per entità o tabella (si veda qui , ad esempio). Tuttavia, quando le tue entità sono uniformi e tutti i tuoi repository sembrano molto simili, può avere senso implementare una classe di repository generica (come mostrato nel precedente link). Questa sarà probabilmente l'alternativa migliore per evitare un numero eccessivo di codice della piastra della caldaia rispetto al repository "big-ball-of-mud".
Tuttavia, la descrizione di Fowler del modello di repository non richiede esplicitamente di avere un repository per entità. Quindi sono d'accordo con Telastyn: quando ci sono dati in bundle, che devono essere tirati e spinti sempre insieme in una query o transazione, può avere più senso avere un repository per più di una tabella.
Eric Evans Domain Driven Design specifica che è necessario fornire un repository per "root aggregati" che necessitano dell'accesso diretto. Quindi questo non è un repository per modello ma un repository per cluster di modelli, se lo desideri. Questo presuppone che tu stia facendo DDD e quindi comprendi il contesto aziendale, però.
Leggi altre domande sui tag architecture design-patterns repository