O que é o Castelo Windsor, e por que eu deveria me importar?

Sou um desenvolvedor de janelas de longa data, tendo cortado os dentes no win32 e no early COM. Trabalho com a. Net desde 2001, por isso sou fluente em C# e CLR. Nunca tinha ouvido falar do Castelo Windsor até começar a participar no Stack Overflow. Li O Guia do Castelo Windsor "começar", mas não bate certo.

Ensina a este velho cão novos truques e diz-me porque devo integrar o Castelo Windsor nas minhas aplicações empresariais.

Author: Matt Hinze, 2008-09-24
Source

4 answers

O Castelo Windsor é uma ferramenta de controlo. Há outros como ele. Pode dar-lhe objectos com dependências pré-construídas e pré-ligadas. um gráfico de objectos inteiro criado através da reflexão e configuração, em vez do operador "novo".

Começa aqui: http://tech.groups.yahoo.com/group/altdotnet/message/10434

Imagine que tem uma aula de envio de E-mail. EmailSender. Imagina que tens outra aula. Trabalha-se bem. Dentro do WorkflowStepper você precisa usar EmailSender. Podes sempre dizer new EmailSender().Send(emailMessage);

Mas isso - o uso de new - cria um acoplamento apertado que é difícil de mudar. (este é um pequeno exemplo inventado afinal)

Então, e se, em vez de te juntares a este mauzão dentro do trabalhador, o passasses para o construtor? Então, quem quer que lhe tenha chamado, tinha de mudar o EmailSender.

new WorkflowStepper(emailSender).Step()

Imagina que tens centenas dessas pequenas classes que só têm uma responsabilidade (Google SRP).. e você usa alguns deles em WorkflowStepper:

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

Imagine não se preocupar com os detalhes de EmailSender Quando você está escrevendo WorkflowStepper ou AlertRegistry

Preocupa-te apenas com a preocupação com que estás a trabalhar.

Imagine todo este gráfico (árvore) de objectos e dependências fica ligado no tempo de execução, de modo que quando fizer isto:

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

Tens um negócio a sério WorkflowStepper com todas as dependências automaticamente preenchidas onde você precisa delas.

Não há new

Acontece porque sabe o que precisa de quê.

E você pode escrever menos defeitos com um código seco e melhor projetado de uma forma testável e repetível.

 331
Author: Matt Hinze, 2014-02-18 17:10:49
Acho que o COI é um passo na direcção certa no caminho para uma maior produtividade e prazer da equipa de desenvolvimento (incluindo PM, BA an BOs). Ele ajuda a estabelecer uma separação de preocupações entre desenvolvedores e para testes. Ele dá paz de espírito ao projetar o que permite flexibilidade como frameworks podem entrar e sair.

A melhor maneira de alcançar a meta que o COI (CW ou Ninject etc..) tenta eliminar a política # 1 e # 2 Remover necessidade de desenvolvedores para colocar na fachada de falsa compreensão ao desenvolver. Estas duas soluções não parecem estar relacionadas com o COI? São:)

 3
Author: Mike Socha III, 2015-02-18 18:46:09

Mark Seemann escreveu e excelente livro sobre DI (injeção de dependência) que é um subconjunto do COI. Ele também compara vários contêineres. Não posso recomendar este livro o suficiente. O nome do livro é: "Dependency Injection in .Net" https://www.manning.com/books/dependency-injection-in-dot-net

 3
Author: IUnknown, 2016-08-11 13:00:28

O Castelo Windsor é {[[0]} significa que, com a ajuda disto, Pode Injectar as suas dependências e usá-las sem as Criar com a ajuda de uma nova palavra-chave. por exemplo, considere que você escreveu um repositório ou um serviço e você deseja usá-lo em muitos lugares, você precisa primeiro registrar seu serviço / Repositório e você pode começar a usá-lo depois de injectá-lo no local necessário. Você pode dar uma olhada no tutorial abaixo que eu segui para aprender Castelo windsor.

Relação

Espero que te ajude.
 1
Author: Rakesh Burbure, 2018-01-30 09:48:15