2012-02-25 15 views
7

Eventuali duplicati:
How do the major C# DI/IoC frameworks compare?Come scegliere un contenitore DI?

Non essendoci tanti contenitori DI, mi sento un po 'perso. Sono nuovo nel modello DI.

Sto leggendo il libro Dependency Injection in .NET e ho trovato DI essere incredibilmente utile nel migliorare un codice di base, rendendolo allentato e più testabile.

Ora voglio introdurre un contenitore DI per il mio progetto fittizio, ma ce ne sono così tanti tra cui scegliere.

Come dovrei scegliere tra Castle Windsor, Unity, StructureMap, Spring.NET, Autofac, Ninject, Funq, LinFu, etc, etc?

Immagino che una soluzione coerente sarebbe quella di "sceglierne solo uno" e iniziare a usarlo (poiché immagino che siano abbastanza facilmente intercambiabili, specialmente nelle fasi iniziali), ma vorrei prendere una decisione più consapevole.

+0

Qualunque cosa tu faccia, non selezionare Funq, perché non supporta l'iniezione automatica del costruttore, che praticamente non lo abilita all'uso su alcun progetto reale, o di fatto lo squalifica come un vero contenitore DI. – Steven

risposta

5

Questo è come comprare una macchina. Potrebbe piacere una Toyota, ma è solo un motore da 2,5 litri. Ti potrebbe piacere la Ferrari, ma è troppo rossa. Potresti gradire Mazda, ma il tuo capo non ti permette di guidarlo. Potresti gradire Hummer, ma i tuoi colleghi rideranno di te. Mescola i produttori secondo i tuoi gusti, ci sarà sempre qualcosa che manca a qualcuno o in un momento diverso.

La mia opinione è che, in primo luogo, DI è solitamente meglio di non avere DI. Scegli qualcosa e starai meglio. Vi consiglio di scegliere qualcosa che:

  • ha un buon supporto in comunità (in modo da poter ottenere risposte)
  • ha una buona società di supporto dietro di esso (in modo da non arrivare a riscrivere il codice quando si va busto)
  • si sente bene a voi (in modo da non giurare davanti ai bambini, non freddo)
  • non è eccessivo per il progetto
  • non è solo dI, ma offre un ecosistema di cose che Riduci il tempo che spendi per le attività che sai che puoi fare, ma non ora - e poi puoi concentrarti sulle cose che contano
  • È utilizzato da molte persone (quindi sai che molte parti sono anche testate nella vita reale e bug riempiti)
  • Non ha 5 anni (come quella documentazione dice che è supportato su Windows 98 o qualcosa del genere

I miei 2 cent - http://www.springframework.net/. Voglio dire, il loro documentation contents page è lungo come 20 pagine ...

O semplicemente potrebbe desiderare di guardare alcuni più risposte a una domanda simile:

2

È possibile iniziare con DependencyResolver incorporato in MVC3. Successivamente è possibile eseguire facilmente l'aggiornamento a Enterprise Library Unity DI.

Brad Wilson aveva menzionato una serie di post su How to use DI in MVC3.

-5

Il contenitore DI più sviluppata per NET è Managed Extensibility Framework (MEF) e vi consiglio vivamente di usarlo . MEF è veloce, facile e manutenibile in tutto il team con una curva di apprendimento perfetta.

+6

* "Il contenitore di DI più sviluppato per .NET è MEF" * - quella dichiarazione generale non è affatto vera per tutto – BrokenGlass

+0

Ho appena condiviso la mia esperienza e ho già utilizzato un sacco di soluzioni DI. Nevermind ... – ogggre

+3

MEF non è un contenitore DI. MEF fornisce la configurazione Plug and Play nella parte superiore di un'implementazione di base. (Come suggerisce il nome è un framework di estensibilità non DI) – Manas

0

La mia posizione è, guarda un po '- hai già l'eccellente libro "Dependency Injection in .NET" (a quella lista aggiungerei Ninject, che sfortunatamente non è coperto nel libro) - e sceglierne uno che capisci meglio e come la sintassi. Per iniziare con le funzionalità avanzate non sono davvero importanti, solo che si avvia.

Una volta che si dispone di un contenitore IoC, la sua sostituzione dovrebbe essere in gran parte insignificante dal momento che tutte le modifiche saranno in un punto - la radice aggregata - e non distribuite su tutto il codice base. L'utilizzo di un contenitore IoC ti costringerà anche a progettare l'iniezione di dipendenza, se non lo hai già fatto, questo sarà l'impatto più grande sui tuoi progetti.

0

Ho utilizzato Ninject e Unity. Quando aggiungi Unity MVC a Unity, il codice mi ricorda il codice Ninject.

Entrambe sono molto facili da implementare. Entrambi consentono la sostituzione di file di configurazione centrici con una centricità di classe di avvio.

Suggerisco di creare un progetto di 2 ore e di implementarlo in ciascuno dei framework di ioc, e decidere per esperienza quale ti piace. Tuttavia, se lo fai senza guardare altre funzionalità potresti scoprire che ti sei perso qualcosa. Quindi, guarda le funzionalità periferiche, come il supporto di terze parti.

0

In aggiunta agli altri fantastici commenti: se si installa il pacchetto Unity.MVC3, è sufficiente fare attenzione a utilizzare HierarchicalLifetimeManager se si desidera che gli oggetti siano disposti con ciascuna richiesta. Ha funzionato benissimo, ma penso che nella maggior parte dei casi troverai che quelli più importanti sono abbastanza carini.

La domanda per te è quella di trovarne uno che si adatti al tuo ambiente. Alcuni luoghi consentono l'open source, alcuni non e in quei casi l'unità vince.

Problemi correlati