•  08-07-2019
  •  | 
  •  

Pergunta

Quais são os prós e contras do uso de @Autowired em uma classe que vai ser ligado por Primavera?

Só para esclarecer, eu estou falando especificamente sobre o @Autowired anotação, não auto-fiação em XML.

Eu provavelmente só não entendo isso, mas para mim parece quase como um anti-padrão - as aulas começam a se tornar ciente de que eles estão vinculados a um quadro DI, ao invés de ser apenas POJOs. Talvez eu sou um glutão de castigo, mas eu gosto de ter a configuração XML externo para o feijão, e eu gostaria de ter fiações explícitas, então eu sei exatamente o que é ligado onde.

Foi útil?

Solução

Por um longo tempo eu acreditava que havia um valor em ter um "centralizado, declarativa, configuração" como os arquivos xml que todos costumava usar. Então eu percebi que a maioria das coisas nos arquivos não era Configuração - foi nunca mudou em qualquer lugar após o desenvolvimento, nunca. Então eu percebi que "centralizado" só tem valor em bastante pequenos sistemas - apenas em pequenos sistemas que você nunca vai ser capaz de Grokar um arquivo de configuração como um todo . E o que é realmente o valor de compreender a fiação como um todo, quando os mesmos "fiações" são na sua maioria duplicada por dependências no código? Assim, a única coisa que eu tenho mantido é meta-dados (anotações), o que é ainda tipo-de declarativa. Estes não mudança em tempo de execução e eles são não de dados "configuração" que alguém vai mudar na mosca -. Então eu acho que mantê-lo no código é agradável

Eu uso auto-fiação completa, tanto quanto eu posso. Eu amo isso. Eu não vou voltar para a primavera de estilo antigo, a menos ameaçado na pistola ponto. Minhas razões para preferir totalmente @Autowired mudaram ao longo do tempo.

Agora eu acho que a razão mais importante para usar autowiring é que há um menos abstração em seu sistema para acompanhar. O "nome do bean" é efetivamente desaparecido. Acontece que o nome do bean só existe por causa do xml. Então uma camada cheia de indireções abstratas (onde você iria ligar feijão-nome "foo" no feijão "bar") está desaparecido. Agora eu conectar a interface "Foo" em meu feijão diretamente, e implementação é escolhido pelo perfil de tempo de execução. Isso me permite trabalho com código quando o rastreamento dependências e implementações. Quando vejo uma dependência autowired no meu código eu posso simplesmente pressione a tecla "ir para a implementação" no meu IDE e até vem a lista de implementações conhecidas. Na maioria dos casos há apenas uma aplicação e eu sou direto para a classe. Não pode ser muito mais simples do que isso, e eu sempre sei exatamente que a implementação está sendo usado (I afirmam que o oposto é mais perto da verdade com a fiação xml - como as alterações engraçadas perspectiva)

Agora você poderia dizer que é apenas uma camada muito simples, mas cada camada de abstração que acrescentamos aos nossos sistemas aumento complexidade. Eu realmente não acho que o xml nunca nenhum valor real para qualquer sistema que eu trabalhei.

A maioria dos sistemas que eu trabalho sempre com apenas têm um configuração do ambiente de tempo de execução de produção. Pode haver outras configurações para teste e assim por diante.

Eu diria que autowiring completo é trilhos ruby-on-de primavera: Ela abrange a noção de que há um padrão normal e comum o uso que a maioria dos casos de uso seguir. Com a configuração XML você autorização um monte de uso configuração consistente / inconsistentes que podem não podem ser destinados /. Eu vi tanta configuração XML ao mar ir com inconsistências - ele se reformulado juntamente com o código? achava que não. essas variações estão lá por uma razão? Normalmente não.

Nós dificilmente usar qualificadores em nossa configuração, e encontrou outras maneiras de resolver essas situações. Esta é uma "desvantagem" clara encontramos: Nós mudamos um pouco o código que maneira de torná-lo interagem mais suave com autowiring: Um repositório cliente implementos já não a interface Repository<Customer> genérico, mas fazemos um CustomerRepository interface que estende Repository<Customer>. Às vezes, há também um truque ou dois quando se trata de subclasses. Mas, geralmente, apenas nos aponta na direção de digitação mais forte, o que eu acho é quase sempre uma solução melhor.

Mas sim, você está amarrando a um estilo particular de DI que na maior parte da primavera faz. Nós nem sequer fazer setters públicos para dependências mais (Então, você poderia argumentar que estamos +1 no departamento de encapsulamento / informação esconderijo) Ainda temos alguns xml em nosso sistema, mas o xml basicamente única contém as anomalias. integra autowiring completos bem com XML.

A única coisa we precisamos agora é para o @Component, @Autowired eo resto para ser incluído em uma JSR (como JSR-250 ), por isso não tem que combinar com a primavera. Esta é a maneira como as coisas foram acontecendo no passado (o material java.util.concurrent vem à mente), então eu não seria totalmente surpreso se isso acontecesse novamente.

Outras dicas

Para mim aqui é o que eu gosto antipatia / sobre Spring e auto-ligação.

Pros:

  • Auto-fiação se livrar de configuração XML desagradável.
  • Muito mais fácil de usar anotações que permite injetar diretamente usando campos, métodos setter, ou construtores. Também permite que você anote e 'qualificar' seus feijões injetados.

Contras:

  • Usando auto-fiação e anotações faz você dependente de bibliotecas do Spring onde como com a configuração XML que você poderia escolher para ser executado com ou sem mola. Como você disse, você se torna ligada a um quadro DI.
  • Ao mesmo tempo, eu gosto de ser capaz de feijão 'qualificar', para mim isso faz com que o código realmente confuso. Se você precisa injetar o mesmo feijão em vários lugares, eu vi o mesmo nome de seqüência repetida por toda parte. Para mim, isso parece ter o potencial de erros.

eu comecei a usar auto-ligação quase que exclusivamente no trabalho porque depende tanto de integração Primavera de qualquer maneira que a questão de dependência é discutível. Eu trabalhei em um projeto Spring MVC que costumava auto-fiação extensivamente e foi um pouco difícil envolver minha cabeça em torno.

Eu penso auto-fiação é um gosto adquirido, uma vez que você se acostumar com isso você percebe o quão poderoso, fácil, e muito menos de uma dor de cabeça que é de trabalhar do que a configuração XML.

Estamos mudando de @Autowire volta à configuração XML em nosso grande projeto. O problema é muito baixo desempenho de inicialização. Autowiring cargas de scanner todas as classes de autowiring pesquisa classpath, por isso, muitas classes são carregadas ansiosamente durante a inicialização da Primavera.

Tem havido muito pouca discussão sobre a mudança ambientes. A maioria dos projetos que eu trabalhei em que era um problema real para dependências injetar, dependendo do ambiente em que está trabalhando. Com configuração XML é bastante simples com a Primavera EL, e eu não tenho conhecimento de qualquer solução agradável com anotações. Eu só descobri um: 

    @Value("#{${env} == "production" ? realService : dummyService}")
    private SomeService service;

Ele deveria estar trabalhando, mas não é uma boa solução imho.

Eu mudei para @Autowire. Manter a configuração XML em outra coisa senão um pequeno projeto tornou-se uma tarefa em seu próprio direito e compreensão rapidamente degradados.

IntelliJ fornece um bom suporte (não perfeito) para anotações de Primavera.

A minha opinião sobre este assunto é que, configuração xml reduzir a clareza do código, especialmente em grandes sistemas.

Anotações como @Component torna as coisas ainda piores. Ele orienta os desenvolvedores para fazer objetos mutáveis, como dependências não podem ser feitas final de mais, dado que construtores padrão precisa ser fornecido. Dependências precisam ser injetado através setter público, ou não controlada através @Autowired. [Injeção de dependência ainda pior é comprometida com as classes que instanciar suas dependências, ainda vejo isso no código recém-escrito!]. Pela média descontrolada I, em grandes sistemas, quando várias implementações (ou filhos) do tipo estão disponíveis, torna-se muito mais envolvidos para entender qual das implementações foi @Autowired, uma complexidade que faz investigando erros muito mais difícil. Isso também significa que, supostamente, você tem um perfil para ambiente de teste e outro para produção, seus erros de produção só vai acontecer quando dói mais - na produção, em vez de ser capaz de detectar os erros no ambiente de teste, ou melhor ainda, em tempo de compilação!

I manter o meio termo, onde eu declaro meus classe de configuração (es), (java baseada Primavera configuração utilizando @Configuration)

Eu declaro todos os meus feijão explicitamente na classe de configuração (ES). Eu só uso @Autowired na classe de configuração (ES), o objetivo é a dependência limite na Primavera para a classe de configuração (es)

O residem @Configuration em um pacote específico, que é o único lugar onde a primavera corridas de digitalização. (Que acelera o tempo de início substancialmente em grandes projetos)

Eu me esforço para fazer todas as minhas aulas imutável, especialmente o objeto de dados, JPA, Hibernate e Spring, assim como muitas bibliotecas de serialização parecem minar isso. Eu abster-se de qualquer coisa que me obriga a fornecer setters, ou remover a palavra-chave final de minha declaração de propriedade.

A redução das possibilidades de mudança objetos depois de serem criados, reduz substancialmente os erros em grande sistema, bem como reduz o tempo para encontrar um bug quando houver.

Parece também que ele força desenvolvedor para melhor projetar a interação entre as diferentes partes do sistema. Problemas e bugs se tornam mais e mais erros de compilação, que reduz o desperdício de tempo e melhorar a produtividade.

Aqui estão algumas das experiências
Pros

  • Faz mais fácil de configurar, porque podemos usar apenas @Autowire anotação
  • Não quero usar métodos setter, então classe será mais limpa

Contras

  • Fortemente casal para arquivo xml apesar de estarmos usando DI
  • Difícil de encontrar implementação (mas se o seu uso ides bom gosto intellij certeza que você pode se livrar deste)

A partir de minhas experiências pessoais eu não usar @AutoWire anotação que muito, mas em casos de teste.

Eu realmente amo escrever com anotações, em vez de XML. De acordo com a Primavera manual eo versões passado, XML e anotação alcançado o mesmo resultado.

Esta é a minha lista

Pro:

  • Remover linha inútil do xml
  • simplificar a depuração do código: quando você abre uma classe, você pode ler o que você tem na classe
  • developping mais rápido, um projeto com 400 ou mais linha de XML é legível?

Contras:

  • Não é a implementação Java padrão, mas você pode alternar para usar @Inject, que é uma norma API Java, de modo que o feijão permanecem um POJO
  • Você não pode simplesmente usar em todos os lugares, db conexão e assim por diante, mas é apenas uma opinião, eu prefiro ter um lugar onde ler toda a configuração.

Para o meu entendimento @Autowired é o melhor para usar quando se referem a referência de interface e usar seus funtions substituição, mas eu só encontrar problema com isso é que, por vezes designado como nulo em tempo de execução.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top