Nella nostra azienda abbiamo una storia relativamente lunga di applicazioni database supportate, ma abbiamo appena iniziato a sperimentare con l'iniezione di dipendenza. Sto cercando consigli su come convertire il nostro schema di accesso ai dati esistente in uno più adatto per l'iniezione delle dipendenze.
Alcune domande specifiche:
Crei un oggetto di accesso per tabella (Dato che una tabella rappresenta una raccolta di entità)?
Un'interfaccia per tabella?
Tutti questi avrebbero bisogno di iniettare l'oggetto Data Access di basso livello, giusto?
Che dire se ci sono dozzine di tabelle, non renderebbe la composizione radice in un incubo?
Avresti invece una singola interfaccia che definisce cose come GetCustomer() , GetOrder() , ecc?
Se prendessi l'esempio di EntityFramework, allora avrei un Container che espone un oggetto per ogni tabella, ma quel contenitore non è conforme a nessuna interfaccia, quindi non sembra compatibile con DI.
Cosa facciamo ora, nel caso in cui aiuti:
Il modo in cui normalmente gestiamo l'accesso ai dati avviene attraverso un livello dati generico che espone funzionalità CRUD / Transaction e ha sottoclassi specifiche del provider che gestiscono la creazione di IDbConnection , IDbCommand , ecc.
L'accesso alla tabella effettiva utilizza le classi Table che eseguono le operazioni CRUD associate a una determinata tabella e accettano / restituiscono gli oggetti dominio che il resto del sistema gestisce. Queste classi di tabelle espongono solo metodi statici e utilizzano un singleton statico DataAccess istanziato da un file di configurazione.