Antipatterns di utilizzo del contenitore IoC. Perché i contenitori IoC sono così complessi e usati in modo "fantasioso"?

Question

Inizio seriamente a pensare che l'utilizzo del contenitore IoC provochi la creazione di soluzioni sovradimensionate (almeno mi provoca l'utilizzo di varie funzioni non necessarie :).

E 'il tempo per sincronizzare la mia lista antipattern "IoC" con la comunità il proprio ..

La mia breve esperienza dicono che è assolutamente sufficiente chiamare il metodo Resolve una volta per ogni applicazione in fase di avvio per risolvere alcuni single di infrastrutture e di avviare con loro "fabbrica di oggetti transitori" che potrebbe produrre nuove "piccole fabbriche di grano a vita". Anche rendere tali stabilimenti thread safe (ad esempio creare un'istanza per thread) è così facile da ottenere aggiungendo 10 linee di codice in fabbrica ... Tuttavia, queste fabbriche sono molto più semplici di "integrazione della libreria con lo strumento IoC". Intercettazione? Basta creare i propri wrapper ... Life Time Manager/strategie di dipendenza/contenitori genitori? Chiama la risoluzione solo una volta al bootstrapper e non ci penserai.

Potresti aiutarmi a capire perché gli sviluppatori chiamano Risolvi più volte su diversi livelli di applicazione (passando il contenitore o passando delegato al contenitore) e poi hanno un sacco di cose a cui pensare? Mi preoccupo davvero che mi manchi qualcosa.

Answer 1

ho trovato qualcuno che forse mi potesse capire :)

Constructor over-injection anti-pattern

Answer 2

Altri antipattern nei miei occhi sta spingendo l'inizializzazione del contenitore "più profondo" bootsrapper poi reale.

Ad esempio Unity and WCF recommendations

Bootstrapper in WCF applicazione è il costruttore servizio, quindi basta mettere inizializzazione contenitore al costruttore. Non capisco i motivi per raccomandare di andare a programmare i comportamenti di wcf sevice e l'host factory di custome sevice: se vuoi avere il bootstrapper "IoC container free" - è assurdo, se hai bisogno di avere l'implementazione del contratto di servizio "IoC container free - basta creare la seconda implementazione del contratto di servizio "IoC container free".

Answer 3

Leggi This

Chiaramente qualcosa di sbagliato. La nuova libreria non dovrebbe portare un codice complesso aggiuntivo.

Answer 4

Alcuni tipi di IoC sono anti-pattern o potrebbero essere in alcuni casi. Ad esempio il service locator antipattern. Ma se stai usando l'iniezione del costruttore all'inizio della tua applicazione - e solo lì - allora lo dovrebbe non portare ad un anti-pattern.

L'iniezione di un'interfaccia contenitore DI in una classe è un uso errato dell'iniezione del costruttore. Se DI non fa parte della business logic della tua classe, non dovrebbe conoscere o dipendere dal contenitore DI né dovrebbe dipendere da IKitchen. Va bene iniettare il contenitore DI in una sorta di helper o servizio che funziona insieme al contenitore dell'iniezione delle dipendenze, perché lo scopo è quello di lavorare con o intorno al contenitore DI. Gli esempi nei link che fornisci sono un uso improprio di IoC. Ciò non significa che l'IoC in generale sia un anti-modello.

Penso che la domanda corretta sarebbe "Può l'iniezione del costruttore essere un anti-pattern?". Finora non ho mai affrontato alcuna situazione o visto alcun esempio in cui era così direi "no", fino a quando non affronterò una situazione del genere.

Answer 5

Quando non mi era chiaro come utilizzare un contenitore IoC, ho deciso di smettere di usarlo, perché pensavo fosse solo una complicazione sulla semplice iniezione di dipendenza.

È vero però che anche senza IoC è possibile cadere nei casi di sovrainiezione. Qualche tempo fa ho letto alcuni post dell'autore di Ninject che mi ha aperto la mente.

Come già sapete, l'iniettore deve essere utilizzato solo all'interno della root di contesto. Tuttavia, al fine di evitare eccessive iniezioni, ho deciso di introdurre un'eccezione alla regola per le fabbriche iniettate.

Nel mio framework, le fabbriche (e solo le fabbriche) possono utilizzare il contenitore dell'iniettore. Le fabbriche sono vincolate nel contenitore nella root di contesto e quindi possono essere iniettate. Le fabbriche diventano delle dipendenze valide e vengono utilizzate per creare nuovi oggetti all'interno di altri oggetti, usando il contenitore dell'iniettore per facilitare l'iniezione delle dipendenze.