IoC e ASP.NET MVC, da dove inizia tutto?

Question

Vedo "IoC" e "DI" menzionati praticamente ovunque per ASP.NET MVC. Benché io sia ben conscio di ... 'tipo di' cosa siano, è uno di quei concetti fluttuanti, quasi ambigui e amorfi, che sembra mi abbiano superato, o semplicemente non sto guardando nel posto giusto. Con la prossima versione di ASP.NET MVC 3.0, la vedo ancora di più. Tanto che sembra che sia tutta una parte della programmazione, semplicemente non so di.

Ho provato a cercare libri sugli argomenti, ma la maggior parte di ciò che trovo sembra fare molte assunzioni (la storia in Ruby, capire cosa è ma non come usarlo, ecc.).

Sto solo chiedendo in anticipo e in modo semplice. Che cos'è è IoC e perché me ne importa? Ci sono siti web decenti che coprono questa prospettiva da un programmatore principiante? Supponi di non sapere nulla a riguardo. Supponi di non sapere altro che C#. Ho letto ogni libro, blog e tutorial su C# da .NET 1.1 a .NET 2.0, e quando .NET 3.5 e LINQ hanno colpito, è diventato così tanto da gestire che non riuscivo a tenere il passo. Sono uno sviluppatore principiante che lavora in ASP.NET MVC/C# e non posso fare a meno di sentire che mi manca qualcosa di molto importante. (Sto avendo molti degli stessi sentimenti per DI (dipendenza da iniezione))

Ho cercato su Google, ho letto blog, ho visto Castle.Windsor, ho visto codice di esempio, ho sfogliato libri e webcast, e sono ancora così al buio. Sembra una di quelle storie al lavoro che sai che dovresti sapere, ma per qualche ragione, non lo fai, e la scuola non mi ha preparato davvero per questo.

StackOverflow ha sempre dimostrato di essere il meglio del meglio nella comunità di sviluppo per me. Attraverso il college, il lavoro introduttivo e il lavoro di freelance di basso livello, ho amalgamato la mia formazione sulla programmazione da parte di altri programmatori (anche se, a quanto ho capito, non è necessariamente qualcosa di cui vergognarsi). Quindi, ancora una volta, sto semplicemente affermando la comunità.

Eh? Non capisco.

Parlando con molti colleghi che cercano di entrare nello stesso campo, molti di loro si sentono allo stesso modo. Quindi non posso fare a meno di sentire da qualche parte lungo la linea, noi programmatori "principianti" abbiamo perso il memo di questi approcci concettuali alla codifica. Mi piacerebbe non solo rispondere a questa domanda, ma penso che una buona discussione per altre persone come me che stanno cercando di capirlo potrebbe essere un'idea intelligente (e se esiste, deve essere resa più ovvia)

Alcuni di quello che ho trovato che è stato utile è stato http://www.theserverside.com/news/1321158/A-beginners-guide-to-Dependency-Injection e http://www.dotnetspark.com/kb/1222-inversion-control--beginner-guide.aspx

ma sto ancora lasciato graffiare la mia testa su una serie di questioni sul perché questo è importante. Sinceramente, ritengo che gran parte della comunità di sviluppatori si senta in questo modo sia sull'IoC che sul Test delle unità. Molto poco è lo che è lo e gli esempi scoperti sono in genere piuttosto scadenti o molto difficili da capire. Quando .NET è stato introdotto, era autonomo. Non avevo bisogno di un mucchio di altri concetti per far girare programmi semplici. Ora, .NET è un linguaggio rispettato e tutto ciò che sta sotto il sole lo sta adottando (nHibernate, MVC, MVP, MVVP, piattaforme di clouding, architettura di gioco, ecc.)

(Sentitevi liberi di indicare se sono solo in flagrante sbagliato, non mi definisco 'buono' con qualsiasi mezzo, ma conosco C# e lo conosco molto bene.Mi considero uno studente molto veloce e con la stessa difficoltà che ho con questo, devo solo supporre che ci sia un buco là fuori che deve essere riempito)

Answer 1

Teniamo da parte tutti i framework IoC e discutiamo il concetto. IoC non è un nuovo concetto ed è in circolazione da molto tempo. IoC è fondamentalmente implementato per rendere il tuo sistema liberamente accoppiato ad alcuni sottosistemi. Otteniamo il disaccoppiamento estraendo il comportamento comune/principale del sottosistema in un contratto. Il contratto è solitamente in forma di interfaccia. Ora dipendi da questa interfaccia. Non sei preoccupato di come un particolare sistema ti dia concretamente il comportamento che cerchi.

Recentemente ho avuto un incontro di vita reale con questo. Stiamo avendo un sistema di pagamento esistente e quindi stiamo sviluppando un nuovo sistema di pagamento per aderire al PCI. Quello che fai in questo tipo di situazione è che estrai le caratteristiche comuni di entrambi i sistemi in un'interfaccia e quindi l'applicazione interagisce con questi due sistemi solo tramite l'interfaccia. È possibile utilizzare un flag nel file di configurazione o nel modello factory o, in definitiva, in un framework IoC per iniettare questa dipendenza nell'applicazione. In fase di esecuzione la tua applicazione otterrà l'oggetto da cui dipende. È necessario DI/IoC in un ambiente in cui vi sia incertezza in merito all'utilizzo di un determinato sottosistema per qualsiasi motivo. In questo esempio, il nuovo sistema di pagamento non ha potuto essere consegnato in tempo e quindi la mia applicazione aveva bisogno di un'opzione configurabile per passare da un sistema all'altro in fase di runtime. Se non faccio IoC, dovrò fare il cambio di codice ogni volta che il business cambia idea.

Un'altra necessità di IoC è di fare TDD. La stessa cosa che ho descritto sopra può essere utilizzata per sviluppare un'implementazione fittizia dell'applicazione reale e può essere utilizzata per eseguire test mentre il componente reale è ancora in fase di sviluppo.

Dependency Injection è un buon libro per iniziare. È anche possibile scaricare un documento gratuito su DI dallo stesso autore here.

Aggiornamento: Aggiunta di codice per maggiore chiarezza

public interface ITest 
    { 
     void Hello(); 
    } 

Ora posso avere due diverse implementazioni concrete:

public class Hi : ITest 
    { 
     public void Hello() 
     { 
      HttpContext.Current.Response.Write("Hi there!"); 
     } 
    } 

    public class HelloMessage : ITest 
    { 
     public void Hello() 
     { 
      HttpContext.Current.Response.Write("Hello there!"); 
     } 
    } 


ITest messenger; 

if (User Needs "Hi") 
{ 
    messenger = new Hi(); 
} 
else if (User Needs "Hello") 
{ 
    messenger = new HelloMessage(); 
} 

messenger.Hello(); 

Tutta la mia applicazione ha a che fare è chiamare il metodo disponibile in contratto. In questo momento l'applicazione sta gestendo le dipendenze in modo esplicito, ma è priva di qualsiasi implementazione concreta. Tuttavia è ancora legato a queste due implementazioni concrete. I framework IoC ci aiutano a esternalizzare questo lavoro a un file di configurazione. Qui posso fornire qualsiasi altra implementazione concreta indipendentemente da come viene implementata e l'applicazione continuerà a funzionare senza modifiche al codice.

Di seguito è riportato il codice in cui sto utilizzando Unity 2 e in outsourcing la gestione esplicita delle dipendenze per conto mio.

using (IUnityContainer container = new UnityContainer()) 
      { 
       container.LoadConfiguration(); 

       ITest messenger = container.Resolve<ITest>(); 

       messenger.Hello(); 
      } 

Config per la stessa:

<unity xmlns="http://schemas.microsoft.com/practices/2010/unity"> 
    <assembly name="Injection"/> 
    <container> 
    <register type="Injection.ITest" mapTo="Injection.Hi"/> 
    </container> 
</unity> 

HTH

Answer 2

Per alcuni video introdotti, controlla DimeCasts.net .

Le due principali ragioni che mi piacciono Ioc:

1. Più facile Unit Testing.
2. Più facile da scambiare i dati di back-end per testare. Supponiamo che tu abbia un IPersonRepository. Il tuo codice implementa un PersonRepository che carica i dati dal database. Ma cosa succede se non si dispone di dati nel database o il database non è ancora impostato? Si utilizza IoC per implementare un DummyPersonRepository che caricherà i dati da qualche altra parte, come un file XML o dati hardcoded.

Answer 3

ho chiesto qualcosa di simile qualche tempo fa, alcune belle risposte laggiù a Examples of IoC Containers

Answer 4

Partenza il video gratuito "Dipendenza Iniezione e inversione del controllo "allo http://tekpub.com/channels/free

Answer 5

Penso che inizierai a cogliere le cose di IoC/DI quando capirai perché e quando viene usato. Non mi preoccuperei troppo di quale contenitore IoC usare. Potresti essenzialmente scrivere da solo un contenitore di base (al livello più elementare è solo un dizionario che mappa un'interfaccia per un'implementazione concreta). Here è un buon video che mostra come sarebbe stato fatto.

Il concetto base è che incoraggia l'accoppiamento lento di componenti, il che significa che il codice è più semplice da testare e non dipende da altre classi concrete.

This link ha dettagli sui principi SOLIDI, la tua domanda riguarda in particolare la "D" (principio di inversione delle dipendenze), ma anche gli altri saranno di interesse.