Quais são as vantagens do contentor de injeção de dependência?

https://stackoverflow.com/questions/131975

02-07-2019
|

Pergunta

Eu entendo benefícios da própria injeção de dependência. Vamos dar Primavera por exemplo. Eu também entendo benefícios de outra Primavera featureslike AOP, ajudantes de diferentes tipos, etc. Eu só estou perguntando, o que são os benefícios de configuração XML, tais como:

<bean id="Mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
  <property name="girlfriend" ref="Mary"/>
</bean>

em comparação com simples código java de idade, tais como:

Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);

que é mais fácil depurado, tempo de compilação verificado e pode ser compreendida por qualquer pessoa que conhece apenas java. Então, qual é a finalidade principal de um quadro de injeção de dependência? (Ou um pedaço de código que mostra seus benefícios.)

UPDATE:
Em caso de

IService myService;// ...
public void doSomething() {  
  myService.fetchData();
}

Como pode IoC quadro palpite da aplicação da myService Quero ser injetado se houver mais do que um? Se há apenas uma implementação de interface de dado, e eu deixei IoC recipiente automaticamente decidir usá-lo, ele será quebrado após uma segunda implementação aparece. E se houver intencionalmente única possível implementação de uma interface, então você não precisa injetá-lo.

Seria muito interessante ver pequeno pedaço de configuração para IoC que mostra seus benefícios. Estou usando o Primavera por um tempo e eu não posso dar exemplo. E eu posso mostrar linhas simples que demonstram benefícios da hibernação, CPF e outras estruturas que eu uso.

UPDATE 2:
Eu percebo que a configuração IoC pode ser alterado sem recompilar. É realmente uma idéia tão boa? Posso entender quando alguém quer mudar as credenciais de banco de dados sem recompilar - ele não pode ser revelador. Em sua prática, quantas vezes alguém além do desenvolvedor alterações de configuração IoC? Eu acho que para os desenvolvedores não há nenhum esforço para recompilar que determinada classe, em vez de alterar a configuração. E para não-desenvolvedor, você provavelmente quer tornar sua vida mais fácil e fornecer algum arquivo de configuração mais simples.

Update 3:

configuração externa do mapeamento entre interfaces e suas implementações concretas

O que é tão bom em fazê-lo extenal? Você não faz todo o seu código externo, enquanto você definitivamente pode - basta colocá-lo no arquivo ClassName.java.txt, ler e compilar manualmente na mosca - wow, você evitou recompilar. Por que compilando ser evitado?!

Você economiza tempo de codificação porque você fornecer mapeamentos declarativa, não em um código processual

Eu entendo que às vezes abordagem declarativa economiza tempo. Por exemplo, eu declaro somente uma vez um mapeamento entre uma propriedade de feijão e uma coluna DB e hibernação usa esse mapeamento durante o carregamento, salvamento, construção de SQL com base em HSQL, etc. Este é o lugar onde as obras Abordagem declarativa. No caso da mola (no meu exemplo), declaração tinha mais linhas e tinha a mesma expressividade como código correspondente. Se há um exemplo, se essa indicação é mais curto do que o código. - Eu gostaria de vê-lo

A inversão do princípio de controle permite o teste de unidade fácil, porque você pode substituir implementações reais com falsos queridos (como a substituição do banco de dados SQL com um um in-memória)

Eu entendo inversão dos benefícios de controle (eu prefiro chamar o padrão de projeto discutido aqui como Dependency Injection, porque IoC é mais geral - existem muitos tipos de controle, e estamos invertendo apenas um deles - o controle de inicialização) . Eu estava perguntando por que alguém sempre precisa de algo diferente de uma linguagem de programação para ele. Eu definitivamente pode substituir implementações reais com falsos que usam código. E este código irá expressar mesma coisa que a configuração -. Ele só irá inicializar campos com valores falsos

mary = new FakeFemale();

Eu entendo benefícios do DI. Eu não entendo o que os benefícios são adicionados pela configuração XML externo em comparação com a configuração de código que faz o mesmo. Eu não acho que comempilhamento deve ser evitado - eu compilar todos os dias e eu ainda estou vivo. Acho configuração do DI é mau exemplo de abordagem declarativa. Declaração pode ser útil se for declarada uma vez e é usado muitas vezes de maneiras diferentes - como hibernate cfg, onde mapeamento entre propriedade do bean e coluna DB é usado para salvar, carregar, construção de consultas de pesquisa, etc. configuração do Spring DI pode ser facilmente traduzido para configuração de código, como no início desta questão, pode não? E ele é usado apenas para a inicialização do feijão, não é? O que significa uma abordagem declarativa não acrescenta nada aqui, não é?

Quando eu declaro mapeamento de hibernação, eu apenas dar hibernar algumas informações, e ele funciona com base nele - eu não digo o que fazer. Em caso de primavera, a minha declaração diz primavera exatamente wht fazer? - então por que declará-lo, por que não fazê-lo

última atualização:
Gente, um monte de respostas estão me contando sobre injeção de dependência, que sei que é bom. A questão é sobre o propósito da configuração DI em vez de inicializar código - I tendem a pensar que a inicialização de código é mais curto e mais claro. A única resposta que obtive até agora para a minha pergunta, é que ele evita recompilar, quando as mudanças de configuração. Acho que eu deveria postar uma outra pergunta, porque é um grande segredo para mim, por que a compilação deve ser evitada neste caso.

Solução

Para mim uma das principais razões para usar um IoC (e fazer uso de configuração externa) está em torno de duas áreas de:

Teste
manutenção de Produção

Teste

Se você dividir o seu teste em 3 cenários (que é bastante normal em desenvolvimento em grande escala):

O teste de unidade
O teste de integração
teste de caixa preta

O que você vai querer fazer é para os dois últimos cenários de teste (Integração & caixa preta), não recompilar qualquer parte do aplicativo.

Se qualquer um dos seus cenários de teste exigem que você alterar a configuração (ou seja: usar outro componente para a integração de uma banca de imitar, ou fazer uma carga de desempenho), isto pode ser facilmente manipulados (este vem sob os benefícios da configuração do DI lado de um IoC embora.

Além disso, se o seu aplicativo é usado tanto em locais múltiplos (com diferentes servidor e configuração de componentes) ou tem uma configuração mudança no ambiente ao vivo, você pode usar as etapas posteriores de testar para verificar se o aplicativo irá lidar com essas mudanças.

Produção

Como um desenvolvedor você não (e não deve) ter o controle do ambiente de produção (em particular quando o seu aplicativo está sendo distribuído para vários clientes ou locais separados), isso para mim é o verdadeiro benefício de usar tanto um IoC e configuração externa, como é até o apoio de infra-estrutura / produção para ajustar e ajustar o ambiente ao vivo, sem ter que voltar para desenvolvedores e através de teste (custo mais elevado quando tudo o que queremos fazer é mover um componente).

Resumo

Os principais benefícios que a configuração externa de um IoC vêm de dar aos outros (não-desenvolvedores) o poder de configurar seu aplicativo, na minha experiência isto só é útil em um conjunto limitado de circunstâncias:

Aplicação é distribuída para vários sites / clientes onde os ambientes será diferente.
controle Development Limited / input sobre o ambiente de produção e instalação.
cenários de teste.

Na prática, descobri que mesmo quando desenvolver algo que você tem controle sobre o ambiente que vai ser executado em, ao longo do tempo, é melhor dar a alguém a capacidade de alterar a configuração:

Ao desenvolver você não sabe quando isso vai mudar (o aplicativo é tão útil sua empresa vende-lo para outra pessoa).
Eu não quero ser preso com a alteração do código cada vez que uma ligeira mudança é solicitado que poderiam ter sido manipulados por configurar e usar um modelo de configuração boa.

Nota:. Aplicação refere-se à solução completa (não apenas o executável), de modo que todos os arquivos necessários para a execução do aplicativo

Outras dicas

Dependência injecção é um estilo de codificação que tem as suas raízes na observação de que a delegação objecto é normalmente um padrão de design mais útil do que a herança objecto (isto é, o objecto tem-uma relação é mais útil do que o objecto é-um relacionamento). Um outro componente é necessário, no entanto para DI de trabalho, o de criar interfaces de objetos. Combinando estes dois padrões de design poderosos engenheiros de software rapidamente perceberam que poderiam criar um código de baixo acoplamento flexível e, portanto, o conceito de Dependency Injection nasceu. No entanto, não foi até objeto reflexão tornou-se disponível em determinadas linguagens de alto nível que DI realmente decolou. O componente de reflexão é fundamental para a maioria dos sistemas de DI de hoje hoje, porque os aspectos muito legal de DI exigem a capacidade de objetos programaticamente selecionar e configurar e injecta-se outros objetos usando um sistema externo e independente para os próprios objetos.

A linguagem deve fornecer um bom suporte para ambas as técnicas de programação orientada a objetos normais, bem como suporte para interfaces de objetos e objeto reflexão (por exemplo, Java e C #). Enquanto você pode construir programas usando padrões DI em sistemas C ++ sua falta de suporte reflexão dentro da linguagem impede adequada, de apoiar servidores de aplicativos e outras plataformas DI e, portanto, limita a expressividade dos padrões DI.

Pontos fortes de um sistema construído usando padrões DI:

DI código é muito mais fácil de reutilizar como a funcionalidade 'dependia' é extrapolada para interfaces bem definidas, permitindo objectos separados cuja configuração é tratado por uma plataforma de aplicação adequado para ser ligado a outros objectos à vontade.
código DI é muito mais fácil de teste. A funcionalidade expressa pelo objeto pode ser testado em uma caixa preta com a construção de 'falsa' objetos implementar as interfaces esperadas pela sua lógica de aplicação.
código DI é mais flexível. É inato de baixo acoplamento código - a um extremo. Isso permite que o programador para escolher e escolher como os objetos estão conectados com base exclusivamente em suas interfaces necessárias em uma extremidade e suas interfaces expressas por outro.
Externo (XML) configuração do DI objetos meios que outros possam personalizar o seu código em direções imprevistas.
configuração externa é também uma separação de preocupação padrão em que todos os problemas de inicialização de objeto e gerenciamento de interdependência objeto pode ser manuseado pelo servidor de aplicativos.
Note que a configuração externa não é necessário para usar o padrão de DI, para interconexões simples um pequeno objeto Builder é muitas vezes suficiente. Há uma troca de flexibilidade entre os dois. Um objeto construtor não é tão opção um flexível como um arquivo de configuração visível externamente. O desenvolvedor do sistema DI deve pesar as vantagens de flexibilidade sobre a conveniência, tomando cuidado para que em pequena escala, controle de grão fino sobre a construção objeto como expresso em um arquivo de configuração pode aumentar os custos de confusão e de manutenção para baixo da linha.

Definitivamente código DI parece mais complicado, as desvantagens de ter todos esses arquivos XML que objetos configurar para ser injetado em outros objetos parece difícil. Esta é, no entanto, o ponto de sistemas DI. Sua capacidade de misturar e código de jogo objetos como uma série de definições de configuração permite que você construa sistemas complexos usando 3ª código de partido com o mínimo de codificação de sua parte.

O exemplo fornecido na questão meramente toca na superfície do poder expressivo que uma biblioteca DI objeto devidamente consignado pode proporcionar. Com alguma prática e um monte de auto-disciplina mais praticantes DI achar que eles podem construir sistemas que têm cobertura de teste de 100% do código do aplicativo. Este ponto só é extraordinário. Este não é 100% de cobertura de teste de uma pequena aplicação de algumas centenas de linhas de código, mas 100% de cobertura de teste applicações compreendendo centenas de milhares de linhas de código. Eu estou em uma perda de poder para descrever qualquer outro padrão de design que fornece este nível de capacidade de teste.

Você está correto em que uma aplicação de apenas 10s de linhas de código é mais fácil de entender do que vários objetos além de uma série de arquivos de configuração XML. No entanto, como com a maioria dos padrões de design poderosos, os ganhos são encontrados como você continuar a adicionar novas funcionalidades ao sistema.

Em suma, as aplicações baseadas DI grande escala são tanto mais fácil de depurar e mais fácil de entender. Enquanto a configuração XML não é 'tempo de compilação verificado' todos os serviços de aplicação que este autor está ciente irá fornecer o desenvolvedor com mensagens de erro se tentar injetar um objeto que tem uma interface incompatível em outro objeto. E a maioria fornecer um recurso 'verificação' que abrange todos conhecida configurações objetos. Isto é facilmente e rapidamente feito através da verificação de que o a-ser-injectado implementa um objeto a interface necessária por objecto B de todas as injecções de objectos configurado.

Este é um pouco de uma pergunta capciosa, mas eu tendem a concordar que enormes quantidades de configuração XML realmente não importa muito benefício. Eu gosto de meus aplicativos para ser o mais leve em dependências quanto possível, incluindo as estruturas pesadas.

Eles simplificar o código um monte de vezes, mas eles também têm uma sobrecarga em termos de complexidade que torna a rastrear problemas bastante difícil (eu vi esses problemas em primeira mão, e em linha reta Java Eu seria muito dealing mais confortável com) .

Eu acho que depende do estilo um pouco, eo que você está confortável com ... você gosta de voar a sua própria solução e têm a vantagem de saber que dentro para fora, ou banco em soluções existentes que pode ser difícil quando o configuração não é apenas para a direita? É tudo uma troca.

No entanto, a configuração XML é um pouco de implicância minha ... Eu tento evitá-lo a todo custo.

A qualquer momento você pode mudar seu código para os dados que você está fazendo um passo na direção certa.

Codificação qualquer coisa como meio de dados que o seu código em si é mais geral e reutilizável. Isso também significa que os seus dados podem ser especificados em uma linguagem que se encaixa exatamente.

Além disso, um arquivo XML pode ser lido em uma GUI ou alguma outra ferramenta e facilmente manipulados de forma pragmática. Como você fazer isso com o exemplo de código?

Estou constantemente factoring coisas maioria das pessoas iria implementar como código em dados, faz o que o código é deixado limpo muito. Acho que é inconcebível que as pessoas vão criar um menu em código ao invés de dados -. Que deveria ser óbvio que fazê-lo no código é errado simplesmente por causa do clichê

A razão para usar um recipiente de DI são que você não tem que ter um bilhão de propriedades pré-configuradas em seu código que são simplesmente getters e setters. Você realmente quer para codificar todos aqueles com o novo X ()? Claro, você pode ter um padrão, mas o contêiner DI permite a criação de singletons que é extremamente fácil e permite que você se concentrar nos detalhes do código, não a tarefa miscelânea de sua inicialização.

Por exemplo, Primavera permite que você implementar a interface InitializingBean e adicione um método afterPropertiesSet (você também pode especificar um "-método init" para evitar acoplamento seu código para Primavera). Estes métodos lhe permitirá assegurar que qualquer interface especificada como um campo em sua instância de classe está configurada corretamente na inicialização, e então você não precisa mais se nulo verificar seus getters e setters (supondo que você permitir que seus singletons para permanecer thread-safe ).

Além disso, é muito mais fácil fazer inicializações complexos com um recipiente DI em vez de fazê-los sozinho. Por exemplo, eu ajudar com o uso XFire (não CeltiXFire, só usamos Java 1.4). O aplicativo usado Spring, mas, infelizmente, usado mecanismo de configuração services.xml do XFire. Quando um conjunto de elementos necessários para declarar que tinha zero ou mais instâncias em vez de um ou mais casos, eu tive que substituir parte do código XFire fornecido por este serviço particular.

Existem certos padrões XFire definidos no seu esquema feijão Primavera. Então, se nós estávamos usando Spring para configurar os serviços, poderia ter sido usado o feijão. Em vez disso, o que aconteceu foi que eu tinha que fornecer uma instância de uma classe específica no arquivo services.xml em vez de usar o feijão. Para fazer isso, eu precisava para fornecer o construtor e configurar as referências declarados na configuração XFire. A verdadeira mudança que eu precisava fazer necessário que eu sobrecarregar uma única classe.

Mas, graças ao arquivo services.xml, eu tive que criar quatro novas classes, estabelecendo seus padrões de acordo com seus padrões nos arquivos de configuração da mola em seus construtores. Se tivéssemos sido capazes de usar a configuração do Spring, que eu poderia ter apenas declarou:

<bean id="base" parent="RootXFireBean">
    <property name="secondProperty" ref="secondBean" />
</bean>

<bean id="secondBean" parent="secondaryXFireBean">
    <property name="firstProperty" ref="thirdBean" />
</bean>

<bean id="thirdBean" parent="thirdXFireBean">
    <property name="secondProperty" ref="myNewBean" />
</bean>

<bean id="myNewBean" class="WowItsActuallyTheCodeThatChanged" />

Em vez disso, parecia mais como esta:

public class TheFirstPointlessClass extends SomeXFireClass {
    public TheFirstPointlessClass() {
        setFirstProperty(new TheSecondPointlessClass());
        setSecondProperty(new TheThingThatWasHereBefore());
    }
}

public class TheSecondPointlessClass extends YetAnotherXFireClass {
    public TheSecondPointlessClass() {
        setFirstProperty(TheThirdPointlessClass());
    }
}

public class TheThirdPointlessClass extends GeeAnotherXFireClass {
    public TheThirdPointlessClass() {
        setFirstProperty(new AnotherThingThatWasHereBefore());
        setSecondProperty(new WowItsActuallyTheCodeThatChanged());
    }
}

public class WowItsActuallyTheCodeThatChanged extends TheXFireClassIActuallyCareAbout {
    public WowItsActuallyTheCodeThatChanged() {
    }

    public overrideTheMethod(Object[] arguments) {
        //Do overridden stuff
    }
}

Assim, o resultado líquido é que quatro classes Java adicionais, principalmente inúteis teve que ser adicionado à base de código para conseguir o efeito que uma classe adicional e algumas informações simples recipiente dependência alcançado. Esta não é a "exceção que confirma a regra", esta é a regra ... lidar com peculiaridades no código é muito mais limpo quando as propriedades já são fornecidos em um recipiente DI e você está simplesmente mudando-los para atender uma situação especial, o que acontece mais frequentemente do que não.

Eu tenho a sua resposta

Existem, obviamente, trade-offs em cada abordagem, mas os arquivos de configuração XML externalizados são úteis para o desenvolvimento empresarial em que sistemas de compilação são usados ??para compilar o código e não o seu IDE. Usando o sistema de compilação, você pode querer injetar certos valores em seu código - por exemplo, a versão da compilação (que poderia ser doloroso ter que atualizar manualmente cada vez que você compilar). A dor é maior quando o seu sistema de construção puxa código fora de algum sistema de controle de versão. Modificando valores simples em tempo de compilação seria necessário que você alterar um arquivo, cometê-lo, compilar e, em seguida, reverter a cada vez para cada alteração. Estes não são mudanças que você quer se comprometer em seu controle de versão.

Outros casos de uso úteis sobre o sistema de compilação e configurações externas:

injetar estilos / folhas de estilo para uma base de código único para diferentes versões
injetar diferentes conjuntos de conteúdo dinâmico (ou referências a eles) para a sua base de código único
injetar contexto de localização para diferentes versões / clientes
mudar um webservice URI para um servidor de backup (quando o principal vai para baixo)

Update: Todos os exemplos acima foram em coisas que não necessariamente requerem dependências em classes. Mas você pode facilmente construir-se casos em que tanto um objeto e automação complexo é necessário - por exemplo:

Imagine que você tinha um sistema em que monitoraram o tráfego do seu site. Dependendo do # de usuários simultâneos, que permite ligar / desligar um mecanismo de registro. Talvez enquanto o mecanismo estiver desligado, um objeto stub é colocado em seu lugar.
Imagine que você tinha um sistema de conferência web em que, dependendo do # dos usuários, você quer mudar a capacidade de fazer P2P dependendo # de participantes

Você não precisa recompilar seu código de cada vez que você mudar alguma coisa na configuração. Ele irá simplificar a implementação e manutenção de programa. Por exemplo, você pode trocar um componente por outro com apenas 1 alteração no arquivo de configuração.

Você pode encaixar em uma nova implementação para namorada. Assim nova fêmea pode ser injetado sem recompilar seu código.

<bean id="jane" class="foo.bar.HotFemale">
  <property name="age" value="19"/>
</bean>
<bean id="mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="john" class="foo.bar.Male">
  <property name="girlfriend" ref="jane"/>
</bean>

(O acima assume fêmea e HotFemale implementar a mesma interface GirlfFriend)

No mundo da NET, a maioria dos quadros de IoC fornecer tanto de configuração XML e código.

StructureMap e Ninject, por exemplo, utilizar interfaces fluentes para recipientes de configurar. Você não está mais restrito aos arquivos de configuração usar XML. Spring, que também existe no .NET, depende fortemente de arquivos XML, uma vez que é a sua interface de configuração principal histórica, mas ainda é possível recipientes configure programaticamente.

A facilidade de combinando configurações parciais forte para uma configuração completa final.

Por exemplo, em aplicações web, o modelo, ver e controladores são tipicamente especificados em arquivos de configuração separados. Use a abordagem declarativa, você pode carregar, por exemplo:

  UI-context.xml
  Model-context.xml
  Controller-context.xml

Ou carga com uma interface de usuário diferente e alguns controladores extras:

  AlternateUI-context.xml
  Model-context.xml
  Controller-context.xml
  ControllerAdditions-context.xml

Para fazer o mesmo no código requer uma infra-estrutura para a combinação de configurações parciais. Não é impossível de fazer no código, mas certamente mais fácil de fazer usando um quadro de IoC.

Muitas vezes, o ponto importante é que está mudando a configuração depois que o programa foi escrito. Com a configuração em código você assume implicitamente que a pessoa mudando ele tem as mesmas habilidades e acesso ao código fonte etc como o autor original tinha.

Em sistemas de produção é muito prático para extrair um subconjunto de configurações (por exemplo, a idade em que você exemplo) para o arquivo XML e permitir por exemplo administrador do sistema ou apoio pessoal para alterar o valor sem dar-lhes o poder total sobre o código-fonte ou outras configurações -. ou apenas para isolá-los de complexidades

A partir de uma Primavera perspecitve eu posso lhe dar duas respostas.

Em primeiro lugar a configuração XML não é a única maneira para definir a configuração. A maioria das coisas pode ser configurado usando anotações e as coisas que devem ser feitas com XML são configuração para o código que você não está escrevendo de qualquer maneira, como um pool de conexão que você está usando de uma biblioteca. 3 de mola inclui um método para definir a configuração DI usando Java semelhante ao enrolados à mão a configuração DI no seu exemplo. Então, usando Spring não significa que você tem que usar um arquivo de configuração baseado em XML.

Em segundo lugar Primavera é muito mais do que apenas um quadro DI. Ela tem muitos outros recursos, incluindo gerenciamento de transações e AOP. As misturas de configuração XML da Primavera todos esses conceitos juntos. Muitas vezes, no mesmo arquivo de configuração que eu estou especificando dependências de feijão, configurações de transação e adicionando escopo de sessão feijão que realmente manipulados usando AOP em segundo plano. I encontrar a configuração XML fornece um lugar melhor para gerir todas estas características. Eu também sinto que a configuração e configuração XML anotação baseada escala até melhor do que fazer a configuração baseada em Java.

Mas eu vejo o seu ponto e não há nada de errado com a definição da configuração injeção de dependência em Java. Eu normalmente faço isso sozinha em testes de unidade e quando eu estou trabalhando em um pequeno o suficiente projeto que eu ainda não adicionou um quadro DI. Eu normalmente não especificar configuração em Java porque para mim isso é o código de canalização tipo que eu estou tentando ficar longe de escrever quando eu escolhi para usar o Spring. Isso é uma preferência, porém, isso não significa que a configuração XML é superior à configuração baseada em Java.

Spring também tem um carregador de propriedades. Usamos este método para variáveis ??definidas que são dependentes do ambiente (por exemplo, desenvolvimento, testes, aceitação, produção, ...). Este poderia ser, por exemplo, a fila para ouvir.

Se não há razão para que a propriedade mudaria, também não há razão para configurá-lo desta forma.

Seu caso é muito simples e, portanto, não precisa de um contêiner IoC (Inversão de Controle) como Spring. Por outro lado, quando você "programa para interfaces, não implementações" (que é uma boa prática em OOP), você pode ter um código como este:

IService myService;
// ...
public void doSomething() {
  myService.fetchData();
}

(note que o tipo de myService é IService - uma interface, não uma implementação concreta). Agora ele pode ser útil para deixar o seu contêiner IoC fornecer automaticamente o exemplo concreto correto de IService durante a inicialização - quando você tem muitas interfaces e muitas implementações, pode ser complicado de fazer isso com a mão. Principais benefícios de um contêiner IoC (quadro de injeção de dependência) são:

configuração externa do mapeamento entre interfaces e suas implementações concretas
IoC alças recipiente algumas questões difíceis, como a resolução de gráficos de dependência complicadas, conseguindo a vida de componente etc.
Você economiza tempo de codificação porque você fornecer mapeamentos declarativa, não em um código processual
A inversão do princípio de controle permite o teste de unidade fácil, porque você pode substituir implementações reais com falsos queridos (como a substituição do banco de dados SQL com um um in-memória)

A inicialização em um arquivo de configuração XML irá simplificar a sua depuração / trabalho adaptando com um cliente que tem seu aplicativo implantado em seus computadores. (Porque não exigir a substituição de recompilação + arquivos binários)

Uma das razões mais atraentes é o " Hollywood princípio ": não chamada nós, vamos chamá-lo. Um componente não é obrigado a fazer as pesquisas para outros componentes e da própria serviços; em vez disso, são fornecidos a ele automaticamente. Em Java, isso significa que ele não é mais necessário é fazer consultas JNDI dentro do componente.

Ele também lotes mais fácil é para teste de unidade de um componente isoladamente:. Em vez de dar uma implementação real dos componentes de que necessita, você simplesmente usar mocks (possivelmente auto gerados)

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow