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

Question

Sono uno sviluppatore di Windows da molto tempo, dopo essermi tagliato i denti su win32 e all'inizio 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 il Castle Windsor & Quot; Guida introduttiva & Quot; guida, ma non fa clic.

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

Answer 1

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

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

Inizia qui: http://tech.groups.yahoo.com/group / altdotnet / messaggio / 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 quello - 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 ha dovuto 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 EmailSender quando scrivi WorkflowStepper o AlertRegistry

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 <=> con tutte le dipendenze compilate automaticamente dove ti servono.

Non è presente <=>

Succede succede - perché sa cosa ha bisogno di cosa.

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

Answer 2

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 i test. Offre tranquillità durante l'architettura, il che consente flessibilità in quanto i quadri possono entrare e uscire.

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

Answer 3

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 è: & Quot; Iniezione delle dipendenze in .Net & Quot; https://www.manning.com/books/dependency-injection-in -dot-net

Answer 4

Castle Windsor è Dependency Injection container. Ciò significa che con l'aiuto di questo puoi iniettare le tue dipendenze e usarle senza crearle con l'aiuto di una nuova parola chiave. per esempio. 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.

link .

Spero che ti possa aiutare.

Answer 5

In parole semplici. 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 al punto in cui l'istanza viene creata.

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.