c# - tutorial - ¿Qué es Castle Windsor y por qué debería importarme?
windsor castle documentation (4)
Soy un desarrollador de Windows desde hace mucho tiempo, habiendo cortado los dientes en win32 y COM temprana. He estado trabajando con .Net desde 2001, así que soy bastante fluido en C # y en CLR. Nunca había oído hablar de Castle Windsor hasta que comencé a participar en Stack Overflow. He leído la guía "Cómo empezar" de Castle Windsor, pero no está haciendo clic.
Enséñale a este viejo perro nuevos trucos, y dime por qué debería integrar Castle Windsor en mis aplicaciones empresariales.
Castle Windsor es Dependency Injection container. Significa que 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 utilizarlo 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 castle windsor.
link .
Espero que te ayude.
Castle Windsor es una herramienta de inversión de control. Hay otros como este.
Puede proporcionarle objetos con dependencias preconstruidas y precableadas allí mismo. Un gráfico de objetos 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. Imagina que tienes otra clase WorkflowStepper. Dentro de WorkflowStepper necesitas usar EmailSender.
Siempre se puede decir new EmailSender().Send(emailMessage);
pero eso, el uso de new , crea un ACOPLAMIENTO FIRMADO 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, acaba de pasarlo 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 que no se preocupa por los detalles de EmailSender cuando está escribiendo WorkflowStepper o AlertRegistry
Solo preocúpate por la preocupación con la que estás trabajando.
Imagine que todo este gráfico (árbol) de objetos y dependencias se conecta en RUN TIME, de modo que cuando haga esto:
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
obtienes una WorkflowStepper real WorkflowStepper con todas las dependencias automáticamente completadas donde las necesites.
No hay new
Simplemente sucede , porque sabe qué necesita qué.
Y puede escribir menos defectos con un código DRY mejor diseñado de forma comprobable y repetible.
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 (incluido PM, BA y BOs). Ayuda a establecer una separación de preocupaciones entre los desarrolladores y para probar. Da tranquilidad cuando la arquitectura permite flexibilidad ya que los marcos pueden entrar y salir.
La mejor manera de lograr el objetivo que IoC (CW o Ninject, etc.) es eliminar es eliminar la política # 1 y # 2 eliminar la necesidad de que los desarrolladores pongan la fachada de la falsa comprensión cuando se desarrollan. ¿Estas dos soluciones no parecen estar relacionadas con IoC? Son :)
Mark Seemann escribió un excelente libro sobre DI (Dependency Injection) que es un subconjunto de IOC. También compara varios contenedores. No puedo recomendar este libro lo suficiente. El nombre del libro es: "Dependency Injection in .Net" https://www.manning.com/books/dependency-injection-in-dot-net