Come gestire il grafico delle dipendenze complesso in IOC?

Question

Come gestire il grafico delle dipendenze complesso in IOC?

#1 da (0 voti)

0

Ho diverse app create da una base di codice (usando moduli comuni). E la mia domanda: come scrivere la composizione di root in questo caso?

Immaginiamo un semplice grafico di dipendenza:

ClassBase --> ClassBase1 --> ClassA
    |
     --> ClassBase2 --> ClassB

1) La prima ipotesi è di avere una radice di composizione grande con tutte le dipendenze da tutte le app.

register ClassBase
register ClassBase1
register ClassBase2
register ClassA
register ClassB

2) La seconda ipotesi è di avere una diversa composizione radice per ogni app. Ma in questo caso devo controllare attentamente quali dipendenze registrare.

Compositon root 1:
    register ClassBase
    register ClassBase1
    register ClassA

Compositon root 2:
    register ClassBase
    register ClassBase2
    register ClassB

vale a dire. se cambio ClassBase2 dipendendo da ClassBase1 avrò un errore di runtime.

Quindi quale approccio è meglio usare in caso di centinaia di dipendenze?

dependency-injection ioc-containers

posta dartNNN 22.05.2018 - 18:16

fonte

1 risposta

Leggi altre domande sui tag dependency-injection ioc-containers

Qual è il termine utilizzato per le azioni automatizzate del bot Web? Che cosa significa che due componenti devono essere connessi?

score 0 · Accepted Answer

Non esiste una salsa segreta per risolvere questi problemi. Quando si eseguono operazioni dinamiche come la configurazione di un oggetto grafico in fase di runtime, è inevitabile che alcuni errori vengano visualizzati solo in fase di esecuzione. Esiste un compromesso tra la flessibilità di IOC e le garanzie statiche nel codice. In generale, paghi questo prezzo per qualsiasi design orientato agli oggetti.

Il modo migliore per mitigare questo è riconoscere che l'insieme di dipendenze scelto nella radice di composizione è codice , anche se può apparire come un file di configurazione. Come possiamo impedire che il codice che abbiamo scritto esploda in produzione? testandolo per primo . In particolare, ciò significa che è necessario testare l'esatta configurazione del contenitore di dipendenza che si prevede di eseguire in produzione. Questo tipo di configurazione DI non è paragonabile alle variabili di configurazione come "dove dovrei inserire il mio file di registro" che è possibile modificare in modo sicuro durante l'implementazione. Qualsiasi modifica alla configurazione DI è una modifica del codice che dovrebbe essere prima di QA.

Questo non rende il CIO inutile. Questo può ancora rendere più facile la produzione rapida di una versione riconfigurata. Il valore principale per l'iniezione delle dipendenze a livello di applicazione è che è possibile iniettare delle simulazioni per il test delle unità. Inversion of Control come strategia di progettazione su scala ridotta è ancora valida (spesso, sotto forma di callback).

Torna alla tua domanda principale: dovresti avere una grande radice di composizione o più piccole? Tre pensieri:

Se quella configurazione è il codice, quindi strutturarlo in modo appropriato. Questo spesso significa dividere una grande fetta di cose in pezzi più piccoli di cose che sono più coese. Se le tue due applicazioni sono essenzialmente separate, la configurazione separata sembra ragionevole.
Possiamo anche chiedere in quali condizioni questa configurazione cambierebbe. Entrambi cambierebbero insieme o potrebbero cambiare separatamente? Il codice che cambia insieme dovrebbe stare insieme.
In molte applicazioni, non si apportano modifiche significative alla configurazione DI di produzione, ma si utilizza solo DI per i test. Quindi, avere una singola radice di composizione può essere molto scomodo per i tuoi test e potresti trarre vantaggio da una struttura più fine.