Che cos'è Castle Windsor e perché dovrei preoccuparmene?

Sono uno sviluppatore di Windows da molto tempo, dopo essermi tagliato i denti su Win32 e all'inizio di COM. Lavoro con .NET dal 2001, quindi sono abbastanza fluente in C # e CLR. Non avevo mai sentito parlare di Castle Windsor fino a quando non ho iniziato a partecipare a Stack Overflow. Ho letto la guida "Guida introduttiva" di Castle Windsor, ma non fa clic.

Insegna a questo vecchio cane nuovi trucchi e dimmi perché dovrei integrare Castle Windsor nelle mie app aziendali.

Castle Windsor è un'inversione di strumento di controllo. Ce ne sono altri simili.

Può darti oggetti con dipendenze precostruite e precablate proprio lì. Un intero oggetto grafico creato tramite la riflessione e la configurazione anziché il "nuovo" operatore.

Inizia qui: http://tech.groups.yahoo.com/group/altdotnet/message/10434

Immagina di avere un corso di invio di email. EmailSender. Immagina di avere un'altra classe WorkflowStepper. All'interno di WorkflowStepper devi usare EmailSender.

Potresti sempre dire new EmailSender().Send(emailMessage);

ma questo - l'uso di new- crea un GIUNTO ATTIVO che è difficile da cambiare. (questo è un piccolo esempio inventato dopo tutto)

E se, invece di rinnovare questo cattivo ragazzo all'interno di WorkflowStepper, lo avessi appena passato al costruttore?

Quindi, chiunque lo chiamasse doveva rinnovare EmailSender.

new WorkflowStepper(emailSender).Step()

Immagina di avere centinaia di queste piccole classi che hanno solo una responsabilità (google SRP) .. e ne usi alcune in WorkflowStepper:

new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()

Immagina di non preoccuparti dei dettagli di EmailSenderquando stai scrivendo WorkflowStepperoAlertRegistry

Ti preoccupi solo della preoccupazione con cui stai lavorando.

Immagina che l'intero grafico (albero) di oggetti e dipendenze venga cablato a RUN TIME, in modo che quando lo fai:

WorkflowStepper stepper = Container.Get<WorkflowStepper>();

ottieni un vero affare WorkflowSteppercon tutte le dipendenze compilate automaticamente dove ti servono.

Non c'è new

Succede e basta , perché sa cosa ha bisogno di cosa.

E puoi scrivere meno difetti con un codice DRY meglio progettato in un modo testabile e ripetibile.

Mark Seemann ha scritto e un eccellente libro su DI (Dependency Injection) che è un sottoinsieme del CIO. Paragona anche un numero di contenitori. Non posso raccomandare abbastanza questo libro. Il nome del libro è: "Iniezione delle dipendenze in .Net" https://www.manning.com/books/dependency-injection-in-dot-net

Penso che l'IoC sia un trampolino di lancio nella giusta direzione sulla strada verso una maggiore produttività e godimento del team di sviluppo (inclusi PM, BA e BO). Aiuta a stabilire una separazione delle preoccupazioni tra gli sviluppatori e per i test. Dà tranquillità quando si progetta, il che consente flessibilità in quanto i quadri possono entrare e uscire.

Il modo migliore per raggiungere l'obiettivo che IoC (CW o Ninject ecc.) Prende a pugni è eliminare la politica n. 1 e n. 2 per eliminare la necessità che gli sviluppatori mettano sulla facciata della falsa comprensione durante lo sviluppo. Queste due soluzioni non sembrano correlate all'IoC? Loro sono :)

Castle Windsor è Dependency Injection container. Significa che con l'aiuto di questo puoi iniettare le tue dipendenze e usarle senza crearle con l'aiuto di una nuova parola chiave. ad es. considera di aver scritto un repository o un servizio e desideri utilizzarlo in molti luoghi, devi prima registrare il tuo servizio / repository e puoi iniziare a usarlo dopo averlo iniettato nel luogo richiesto. Puoi dare un'occhiata al tutorial qui sotto che ho seguito per imparare il castello di Windsor.

collegamento .

Spero che ti possa aiutare.

In poche parole. Immagina di avere qualche classe sepolta nel tuo codice che necessita di alcuni semplici valori di configurazione per fare il suo lavoro. Ciò significa che tutto ciò che crea un'istanza di quella classe deve ottenere tali dipendenze, quindi di solito si finisce per rifattorizzare un sacco di classi lungo la strada per passare un po 'di configurazione fino a dove viene creata l'istanza.

Quindi o molte classi vengono inutilmente modificate, raggruppi i valori di configurazione in una grande classe di configurazione che è anche cattiva ... o peggio ancora vai Service Locator!

IoC consente alla tua classe di ottenere tutte le sue dipendenze senza quella seccatura e gestisce la vita delle istanze in modo più esplicito.