Qu'est-ce que Castle Windsor et pourquoi devrais-je m'en soucier?

Question

Je suis un développeur Windows de longue date, ayant fait mes armes dans win32 et le début de COM. Je travaille avec .Net depuis 2001, donc je parle assez bien C # et le CLR. Je n'avais jamais entendu parler de Castle Windsor avant de commencer à participer à Stack Overflow. J'ai lu le Castle Windsor & "Pour commencer &"; guide, mais ce n'est pas en cliquant.

Apprenez à ce vieux chien de nouvelles astuces et dites-moi pourquoi je devrais intégrer Castle Windsor à mes applications d'entreprise.

Answer 1

Castle Windsor est un outil d’inversion de contrôle. Il y en a d'autres comme ça.

Il peut vous donner des objets avec des dépendances pré-construites et pré-câblées. Un graphe d'objet entier créé via la réflexion et la configuration plutôt que le & "nouveau &"; opérateur.

Commencez ici: http://tech.groups.yahoo.com/group / altdotnet / message / 10434

Imaginez que vous ayez un cours d’envoi d’e-mails. EmailSender. Imaginez que vous avez une autre classe WorkflowStepper. Dans WorkflowStepper, vous devez utiliser EmailSender.

Vous pouvez toujours dire new EmailSender().Send(emailMessage);

mais cela - l’utilisation de new - crée un couplage étroit qui est difficile à changer. (c’est un petit exemple artificiel après tout)

Et si, au lieu de changer ce mauvais garçon dans WorkflowStepper, vous venez de le transmettre au constructeur?

Ainsi, celui qui l'a appelé devait créer un nouvel EmailSender.

new WorkflowStepper(emailSender).Step()

Imaginez que vous avez des centaines de ces petites classes qui n'ont qu'une responsabilité (google SRP) .. et que vous en utilisez quelques-unes dans WorkflowStepper:

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

Imaginez ne pas vous soucier des détails de EmailSender lorsque vous écrivez WorkflowStepper ou AlertRegistry

Vous ne vous inquiétez que de la préoccupation avec laquelle vous travaillez.

Imaginez que tout ce graphique (arbre) d'objets et de dépendances soit câblé au moment de l'exécution, de sorte que lorsque vous procédez ainsi:

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

vous avez une vraie affaire <=> avec toutes les dépendances automatiquement remplies là où vous en avez besoin.

Il n'y a pas de <=>

Cela arrive - car il sait ce qui a besoin de quoi.

Et vous pouvez écrire moins de défauts avec un code DRY mieux conçu, testable et reproductible.

Answer 2

Je pense que IoC est un tremplin dans la bonne direction sur la voie d'une productivité accrue et du plaisir de l'équipe de développement (y compris les PM, BA et BO). Cela aide à établir une séparation des préoccupations entre les développeurs et pour les tests. Cela donne une tranquillité d’esprit lors de l’architecture, ce qui permet une certaine flexibilité car les cadres peuvent entrer et sortir.

Le meilleur moyen d’atteindre l’objectif recherché par IoC (CW ou Ninject, etc.) est d’éliminer les politiques n ° 1 et n ° 2, de supprimer la nécessité pour les développeurs de mettre en avant une fausse compréhension lors de leur développement. Ces deux solutions ne semblent-elles pas liées à l'IoC? Ils sont:)

Answer 3

Mark Seemann a écrit un excellent livre sur DI (Dependency Injection), qui est un sous-ensemble de IOC. Il compare également un certain nombre de conteneurs. Je ne peux pas assez recommander ce livre. Le nom du livre est: & "; Injection de dépendance dans .Net &"; https://www.manning.com/books/dependency-injection-in -dot-net

Answer 4

Castle Windsor est Dependency Injection container. Cela signifie que vous pouvez ainsi injecter vos dépendances et les utiliser sans les créer à l’aide d’un nouveau mot clé. par exemple. Considérez que vous avez écrit un référentiel ou un service et que vous souhaitez l’utiliser à de nombreux endroits. Vous devez d’abord enregistrer votre service / référentiel et vous pouvez commencer à l’utiliser après l’avoir injecté à l’emplacement requis. Vous pouvez consulter le didacticiel ci-dessous que j'ai suivi pour apprendre Castle Windsor.

link .

J'espère que cela vous aidera.

Answer 5

En termes simples. Imaginez que votre code contienne une classe qui nécessite quelques valeurs de configuration simples pour faire son travail. Cela signifie que tout ce qui crée une instance de cette classe doit obtenir ces dépendances. Vous devez donc généralement refactoriser les charges de classes en cours de route pour transmettre un peu de configuration jusqu'à l'endroit où l'instance est créée.

Donc, soit beaucoup de classes sont modifiées inutilement, vous regroupez les valeurs de configuration dans une seule grande classe de configuration également mauvaise ... ou, pire encore, Service Locator!

IoC permet à votre classe d’obtenir toutes ses dépendances sans tracas et gère plus explicitement la durée de vie des instances.