Modello di fabbrica astratto in cima a IoC?

Ho deciso di utilizzare i principi IoC su un progetto più ampio. Tuttavia, mi piacerebbe ottenere qualcosa di dritto che mi dava fastidio da molto tempo. La conclusione che ho trovato è che un contenitore IoC è un modello architettonico, non un modello di progettazione. In altre parole, nessuna class dovrebbe essere consapevole della sua presenza e il contenitore stesso dovrebbe essere usato a livello di applicazione per ricucire tutti i componenti. Essenzialmente, diventa un’opzione, oltre a un modello orientato agli oggetti ben progettato. Detto questo, come è ansible accedere a tipi risolti senza sprecare contenitori IoC ovunque (indipendentemente dal fatto che siano astratti o meno)? L’unica opzione che vedo qui è quella di utilizzare fabbriche astratte che usano un contenitore IoC per risolvere tipi concreti. Questo dovrebbe essere abbastanza facile da sostituire per una serie di fabbriche standard. è un buon approccio? Qualcuno qui ha usato e quanto bene ha funzionato per te? C’è qualcos’altro disponibile?

Grazie!

Come hai già capito, Dependency Injection (DI) è di per sé solo una raccolta di schemi e tecniche.

Alla radice dell’applicazione colleghiamo tutti i grafici degli oggetti necessari. Questo posto è chiamato Composizione Root , e possiamo usare un contenitore DI per fare questo cablaggio per noi, oppure possiamo farlo manualmente ( DI puro ).

Il punto è che nella tua applicazione c’è solo un posto dove c’è un forte riferimento a una particolare tecnologia (il tuo DI Container). Il resto dell’app è beatamente inconsapevole di come è stato cablato il grafo degli oggetti: tutto ciò che conta è che tutte le dipendenze richieste siano state iniettate correttamente (e si può usare Constructor Injection con Null Guard per garantire che sia così).

Il pattern Abstract Factory è un modello molto utile quando si tratta di DI. In sostanza, usa Abstract Factory quando:

  • È necessario fornire uno o più parametri noti solo in fase di esecuzione prima di poter risolvere una dipendenza.
  • La durata della dipendenza è concettualmente inferiore alla durata del consumatore.

Esempi e ulteriori informazioni sono disponibili qui:

  • Esiste un modello per inizializzare gli oggetti creati tramite un contenitore DI
  • Imansible combinare Factory / DI
  • Quale contenitore DI lo soddisferà
  • Dove devo fare l’iniezione con Ninject 2+ (e come posso disporre i miei moduli?)
  • Design – Dove devono essere registrati gli oggetti quando si usa Windsor

Bene, nella parte più alta della tua applicazione avrai bisogno di una class Bootstrap che carichi il contesto IOC. Questo contesto fornirà quindi gli oggetti effettivamente istanziati e quindi agirà come una fabbrica.

Ma questo dovrebbe accadere solo con pochissimi oggetti e l’utente della class Bootstrap / Factory dovrebbe conoscere il meno ansible l’architettura sottostante. Ad esempio se hai configurato un object server HTTP completamente tramite IOC e vuoi avviarlo, la tua class Bootstrap deve solo fornire un metodo getHttpServer (). Quindi il metodo principale del tuo programma deve solo chiamare Bootstrap.getHttpServer (). Start () per farlo funzionare.

Il cablaggio degli altri oggetti è già stato fatto dal contesto dell’applicazione, ad esempio si configura l’object A tramite IOC che fa parte dell’object B, quindi si configura l’object B con il riferimento all’object A. Nessuno di questi di solito deve conoscere né il contenitore né la fabbrica.