Esempi di contenitori IoC

Qualcuno ha dei buoni esempi di contenitori IoC (preferibilmente in c #) e come e perché usarli? Ho controllato la pagina wiki e l’ esempio di Ayende , ma non ho ancora capito il concetto.

E quando e dove dovrei usare un contenitore IoC?

Ho usato un po ‘la mappa delle strutture . Il resto della tua domanda è abbastanza carico. Proverò a spiegare il concetto in un esempio.

Supponiamo che tu abbia creato un sito web che accetterà pagamenti tramite PayPal. PayPal è ora una dipendenza. Ma non vuoi codificare contro uno specifico provider PayPal.

Invece dovresti creare e codificare su un’interfaccia come questa ..

interface IPaymentProcessor { bool ProcessPayment(amount, ....); } 

Tutto il tuo codice paypal risiederà in una class che implementa i metodi della tua interfaccia. PayPalPaymentProcessor per esempio

Ora hai un object che utilizzerai per elaborare i pagamenti. Questo potrebbe essere un controller (asp.net-mvc, ViewModel-wpf) o solo una class come mostrato qui.

 class PaymentProcessor { private IPaymentProcessor _processor = null; public PaymentProcessor(IPaymentProcessor processor) { _processor = processor; } public bool ProcessTransaction(Transaction trans) { _processor.ProcessPayment(trans.amount, ...); } } 

Qui entra in gioco un IoC. Invece di chiamare manualmente il costruttore, lasceresti che un IoC inietti la dipendenza.

 PaymentProcessor processor = ObjectFactory.GetInstance(); 

Questo pezzo di codice indica la mappa della struttura “Ogni volta che vedi un costruttore che ha bisogno di un IPaymentProcessor, restituisci un nuovo PayPalPaymentProcessor”.

 ObjectFactory.Initialize(x => { x.ForRequestedType().TheDefaultIsConcreteType(); }); 

Tutta questa mapping è separata dal tuo codice di implementazione e potresti cambiarli in un secondo momento con un minimo di refactoring necessario. C’è molto di più per IoC, ma questo è un concetto di base. È ansible automatizzare l’iniezione di costruttori per evitare anche le chiamate direttamente a ObjectFactory.

Spero che questo ti aiuti!

Essere consapevoli dei seguenti limiti del contenitore IOC. Devo avvisare le persone, perché vivo con l’inferno di dover supportare un sistema che lo utilizza:

  • Le eccezioni lanciate dai costruttori vengono inghiottite. Si ottiene solo l’eccezione “imansible creare dipendenza”. Ciò significa che non è ansible rilevare le eccezioni previste se si lancia in un costruttore.
  • Imansible passare attraverso i costruttori.
  • Dimenticare di registrare un’interruzione di un’interfaccia in fase di esecuzione invece che in fase di compilazione.
  • Tutte le tue classi possono avere solo un costruttore e tutti devono accettare le interfacce come parametri.
  • Tutte le dipendenze sono istanziate, quindi non è ansible condividere istanze, il che significa che l’utilizzo della memoria può diventare grande rapidamente.
  • Promuove molte interdizioni che possono hide il fatto che il codice è diventato spaghetti. Rendere più facile l’instaziare tutte queste interdipen- ze basta a mascherare l’esistenza di un potenziale problema di fondo.
  • Non è ansible gestire la propria “Unità di lavoro” molto facilmente perché non è ansible gestire una transazione tra più dipendenze poiché non si ha il controllo di istanziarle e passare nel contesto di tale transazione.

Non fraintendetemi, amo l’iniezione di dipendenza e l’inversione del principio di controllo, ma penso che il contenitore CIO possa essere usato in modo responsabile, ma solo essere consapevoli delle battaglie che dovrete combattere a causa della lista di cui sopra.

Se vuoi vedere un contenitore IoC sotto il cofano, e anche il punto (Dependency Injection), c’è un grande podcast su DNR TV ( episodio 126 ) che entra davvero nei dettagli su come crearli, perché ne hai bisogno. È un podcast davvero meraviglioso. Dopo aver guardato questo video, potrai guardare Unity , Ninject , StructureMap , ecc. E essere in grado di capire cosa stanno facendo

Scopri Spring IoC (.net) un contenitore java / .net. La documentazione è piuttosto buona introduzione.

In breve: puoi pensare a IoC come a un’architettura che incoraggia: composizione di oggetti e programmazione a un’interfaccia .

Questo ti dà il seguente:

  • la capacità di testare facilmente il codice (puoi facilmente testare i tuoi oggetti isolandoli prendendo in giro tutte le sue dipendenze).

  • Una configurazione estremamente avanzata (perché il tuo programma con IoC è solo un mucchio di oggetti e una configurazione che unisce gli oggetti insieme).

  • La possibilità di estendere o modificare l’applicazione compilata da byte (questo è vero per Java Non sono sicuro se è vero per .net).

Usiamo Ninject a causa della sua semplice API e risoluzione veloce degli oggetti. È molto ben documentato e sfrutta le caratteristiche del C # 3.0 come espressioni lambda per semplificare le specifiche.

Qui puoi trovare diversi screencast su Ninject

Di solito uso StructureMap , principalmente perché conosco la syntax. Ho anche sentito parlare bene di autofac e non vedo l’ora di provare Ninject quando arriva alla v2.

Potresti dare un’occhiata a questa risposta in cui parlo di un utilizzo di base di un contenitore IoC (penso sempre che le cose siano più facili da capire con un semplice esempio) – questo potrebbe aiutarti a capire un po ‘di più le cose. In sostanza, il contenitore IoC consente di creare oggetti con tutte le dipendenze soddisfatte e consente di modificare le dipendenze con un codice di configurazione minimo.

Prova a leggere Introduzione a Unity Application Block e in ASP.NET StoreFront: Dependency Injection screencast puoi vedere di più sui concetti di Iniezione di dipendenza.

Stai cercando di creare un contenitore IoC perché non utilizzare uno di quelli disponibili come Spring.NET, StructureMap o Unity Application Block? Ecco un elenco di progetti IoC open source

Sto usando Unity per il mio contenitore IoC, ma la differenza tra i contenitori risiede in più di quello che puoi fare con DI.

DI (Dependency Injection) è principalmente un modo per ottenere un accoppiamento più libero tra le parti più disparate del tuo programma. Quindi, se hai scritto un gioco che ti piace come funziona, utilizzando DI puoi modificare i personaggi o il motore fisico nel gioco senza modificare altre parti del gioco, quindi, se qualcuno paga più soldi, ottiene il motore più realistico, o i personaggi migliori, ma poiché non cambia nulla, il test è più semplice.

Il test delle unità è anche più semplice con DI, poiché è ansible prendere in giro il database, ad esempio, semplicemente cambiando l’implementazione che verrà utilizzata dall’applicazione, senza influire su nient’altro.

Ad esempio, se utilizzi Spring.NET, avrai accesso a un framework molto potente, ma potrebbe non funzionare molto, quindi cerca qualcosa di più piccolo. Penso che la regola migliore sia trovare l’implementazione più piccola e più semplice che soddisfi le tue esigenze e usarla.