Can Dependency Injection utilizzato come alternativa a Reflection per la creazione di istanze

Probabilmente dipende da una serie di domande:

• Quante istanze dell'oggetto crei in fase di runtime? Se c'è un piccolo numero finito, tenderei a DI, se ci sono molti numeri in momenti diversi tenderei a riflettere
• Quali argomenti prende il costruttore di oggetti? Se variano in fase di esecuzione, la riflessione può essere migliore, ma se sono sempre noti in anticipo, è possibile che si stia utilizzando la DI.
  • Cosa c'è di sbagliato nell'attuale implementazione? Non soddisfa i requisiti, è difficile da supportare o ti stai solo rifattendo? Cosa ti piacerebbe ottenere e sarebbe DI aiutare in quegli obiettivi?

Vale anche la pena sottolineare che i framework DI useranno comunque la reflection sotto il cofano per creare oggetti in fase di runtime.

Come approccio generale, penso che puoi sostituire un codice che utilizza Activator.CreateInstance con Factory . La fabbrica può accettare un parametro che è possibile utilizzare per selezionare il tipo corretto da creare e quindi risolvere tale tipo utilizzando il contenitore IoC. Ad esempio Castle Windsor come una caratteristica chiamata Typed Factory che può fare tutto il lavoro per il tuo.

Ad esempio se hai il seguente codice:

var component = (MyService)Activator.CreateInstnace(myImplementationType, [params]);

Puoi sostituire con qualcosa di simile

var component = myFactory.Create(params);

o

var component = myFactory.Create<MyService>([params]);

Un altro approccio che può essere utilizzato è quello di invertire la dipendenza (Inversion of Control) e lasciare che il componente principale decida quali componenti iniettare. Questo è l'approccio raccomandato nella maggior parte delle situazioni. Dal principale è possibile registrare l'implementazione corretta e lasciare che la Dipendenza dell'iniezione faccia funzionare.