StructureMap DI sull'assemblaggio del modello

Question

Sono nuovo in Dependency Injection e avevo una domanda / bisogno di assistenza.

Avevo un'applicazione che utilizzava il modello di repository per l'accesso ai dati. Ho usato StructureMap per ottenere il repository corretto e tutto ha funzionato bene.

Da allora ho suddiviso il mio modello (inclusa la logica del repository) nel proprio assembly e ho aggiunto un livello di servizio. Nell'interesse di DI la classe del livello di servizio prende un IRepository nel suo costruttore. Questo mi sembra sbagliato dato che ora tutti i consumatori del mio modello devono conoscere il repository (almeno configurare il proprio DI per sapere quale utilizzare). Sento che sta entrando nelle viscere del modello.

Cosa sembra sbagliato in questo?

Answer 1

Un'applicazione scritta per utilizzare l'iniezione di dipendenza in genere configura una singola istanza del contenitore in cui tutte le mappature del tipo di interfaccia / implementazione sono state registrate in una fase di inizializzazione dell'applicazione. Ciò include la registrazione dei repository, dei servizi e di tutti gli utenti del servizio all'interno dell'applicazione.

Risolvendo i consumatori del servizio attraverso il container, i consumatori devono solo indicare la loro dipendenza dal servizio, non le dipendenze di cui il servizio potrebbe aver bisogno. Pertanto, i consumatori del servizio non saranno accoppiati alle sue dipendenze (ad esempio il tuo repository). Questo è il vantaggio di fare l'iniezione di dipendenza attraverso un contenitore invece di fare l'iniezione manuale di dipendenza.

Se stai progettando servizi che verranno utilizzati da altre applicazioni sotto forma di libreria riutilizzabile, le tue opzioni varieranno a seconda del livello di flessibilità che desideri offrire.

Se si presume che tutti i client della libreria utilizzeranno l'iniezione delle dipendenze, sarà necessario fornire una quantità adeguata di documentazione su quali tipi devono essere registrati nel loro contenitore.

Se si presume che tutti i client utilizzeranno un contenitore specifico (ad esempio StructureMap), è possibile facilitare i requisiti di registrazione fornendo registri che incapsulano tutte le esigenze di registrazione specifiche per il cliente.

Se si desidera consentire alla propria libreria di essere utilizzata dai client che non utilizzano il proprio contenitore di iniezione delle dipendenze, è possibile fornire una fabbrica statica che restituisce il servizio. A seconda del livello di complessità, un tale scenario potrebbe non richiedere l'uso di un contenitore (ad esempio, se il servizio è composto da pochi oggetti in tutto). Se la tua biblioteca è composta da una notevole quantità di componenti che devono essere composti, potresti avere fabbriche che risolvono i servizi attraverso le loro esigenze di inizializzazione dell'infrastruttura interna condivisa.

Answer 2

Capisco il tuo dilemma lì, Dan, anch'io ho trascorso molto tempo a lottare su questo nella mia mente. Credo che il modo in cui ho deciso di andare avanti sia stato uno dei modi migliori per incapsulare tutte le preoccupazioni e avere ancora oggetti facilmente accoppiabili liberamente mantenibili.

Ho scritto questo post sul blog in particolare su NHiberante ma se guardi il modello di repository nell'attrezzo puoi facilmente cambiare il codice specifico NH per usare il tuo backingstore.

Creazione di un repository NHiberate generico generico ed estensibile