¿Qué es Castle Windsor y por qué debería importarme?

Soy un desarrollador de Windows desde hace mucho tiempo, que me corté los dientes en win32 y principios de COM. He estado trabajando con .NET desde 2001, por lo que soy bastante fluido en C # y CLR. Nunca había oído hablar de Castle Windsor hasta que comencé a participar en Stack Overflow. He leído la guía "Comenzando" de Castle Windsor, pero no está haciendo clic.

Enséñele a este viejo perro nuevos trucos y dígame por qué debería integrar Castle Windsor en mis aplicaciones empresariales.

Castle Windsor es una herramienta de inversión de control. Hay otros como este.

Puede darle objetos con dependencias preconstruidas y cableadas allí mismo. Un gráfico de objeto completo creado a través de la reflexión y la configuración en lugar del operador "nuevo".

Comience aquí: http://tech.groups.yahoo.com/group/altdotnet/message/10434

Imagina que tienes una clase de envío de correo electrónico. EmailSender. Imagine que tiene otra clase WorkflowStepper. Dentro de WorkflowStepper necesita usar EmailSender.

Siempre puedes decir new EmailSender().Send(emailMessage);

pero eso, el uso de new, crea un ACOPLAMIENTO APRETADO que es difícil de cambiar. (Este es un pequeño ejemplo artificial después de todo)

Entonces, ¿qué pasa si, en lugar de renovar a este chico malo dentro de WorkflowStepper, lo pasa al constructor?

Entonces, quien lo llamó tuvo que actualizar el EmailSender.

new WorkflowStepper(emailSender).Step()

Imagine que tiene cientos de estas pequeñas clases que solo tienen una responsabilidad (google SRP) ... y usa algunas de ellas en WorkflowStepper:

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

Imagine no preocuparse por los detalles de EmailSendercuándo está escribiendo WorkflowStepperoAlertRegistry

Simplemente te preocupas por la preocupación con la que estás trabajando.

Imagine que todo este gráfico (árbol) de objetos y dependencias se conecta en el TIEMPO DE EJECUCIÓN, de modo que cuando haga esto:

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

obtienes un trato real WorkflowSteppercon todas las dependencias que se completan automáticamente donde las necesitas.

No hay new

Simplemente sucede , porque sabe lo que necesita qué.

Y puede escribir menos defectos con un código DRY mejor diseñado de forma comprobable y repetible.

Mark Seemann escribió un excelente libro sobre DI (Dependency Injection), que es un subconjunto del COI. También compara una serie de contenedores. No puedo recomendar este libro lo suficiente. El nombre del libro es: "Inyección de dependencias en .Net" https://www.manning.com/books/dependency-injection-in-dot-net

Creo que IoC es un trampolín en la dirección correcta en el camino hacia una mayor productividad y disfrute del equipo de desarrollo (incluidos PM, BA y BO). Ayuda a establecer una separación de preocupaciones entre los desarrolladores y para las pruebas. Da tranquilidad al diseñar, lo que permite flexibilidad ya que los marcos pueden entrar y salir.

La mejor manera de lograr el objetivo que IoC (CW o Ninject, etc.) apuñala es eliminar la política # 1 y # 2 para eliminar la necesidad de que los desarrolladores se pongan en la fachada de la falsa comprensión al desarrollar. ¿Estas dos soluciones no parecen estar relacionadas con IoC? Son :)

Castle Windsor es. Dependency Injection container.Con la ayuda de esto, puede inyectar sus dependencias y usarlas sin crearlas con la ayuda de una nueva palabra clave. Por ejemplo, considere que ha escrito un repositorio o un servicio y desea usarlo en muchos lugares, primero debe registrar su servicio / repositorio y puede comenzar a usarlo después de inyectarlo en el lugar requerido. Puedes echar un vistazo al siguiente tutorial que seguí para aprender el castillo de Windsor.

enlace .

Espero que te ayude.

En pocas palabras. Imagine que tiene alguna clase enterrada en su código que necesita algunos valores de configuración simples para hacer su trabajo. Eso significa que todo lo que crea una instancia de esa clase necesita obtener esas dependencias, por lo que generalmente tendrá que refactorizar un montón de clases en el camino para pasar un poco de configuración al lugar donde se crea la instancia.

Entonces, o muchas clases se alteran innecesariamente, agrupa los valores de configuración en una gran clase de configuración que también es mala ... ¡o peor aún, vaya al Localizador de servicios!

IoC le permite a su clase obtener todas sus dependencias sin esa molestia, y también maneja vidas de instancias más explícitamente.