Spring - Confusão sobre configuração?

Em algum lugar que li, o Spring oferece conveniência sobre a configuração. Mas o pessoal do Spring está trazendo tantas mudanças na configuração, que agora estou realmente ficando confuso ao usar a configuração xml ou a anotação.

Gostaria que alguém sugerisse uma metodologia ou regra prática infalível no uso de xml e anotações.

Exemplos no SO para mostrar que muitos iniciantes como eu estão ficando confusos com a configuração.

• link-1

  Não pareço entender a funcionalidade por trás <context:annotation-config>e <context:component-scan>.

  Pelo que li, eles parecem lidar com anotações diferentes (@Required, @Autowired etc vs @Component, @Repository, @Service etc), mas também pelo que li, eles registram as mesmas classes de pós-processador de bean.

  Para me confundir ainda mais, há um annotation-configatributo em <context:component-scan>...

• link 2

  Ainda tenho a tag de verificação de componente:

  <context:component-scan base-package="com.mycompany.maventestwebapp" />

  mas também tenho outra tag (que parece ter uma tarefa semelhante), esta:

  <annotation-driven />

  Qual é a diferença entre essas duas tags? Outra coisa "estranha" é que o exemplo anterior (que não usa a tag acionada por anotação) é muito semelhante ao projeto criado pelo STS usando o projeto Spring MVC Template, mas se eu excluir a tag acionada por anotação de sua configuração arquivo o projeto não é executado e me dá o seguinte erro: Status HTTP 404 - ...

O Spring 3.2 não precisa mais do cglib para proxy, mas as versões inferiores usam o cglib. Uma citação do blog da springsource

Para gerar esses proxies, o Spring usa uma biblioteca de terceiros chamada cglib. Infelizmente, este projeto não está mais ativo. No Spring 3.2, é muito provável que o Spring esteja usando Javassist, por padrão.

São suficientes para sugerir que o Spring é Confusion over configuration?

O Spring tem como objetivo fornecer uma estrutura onde há "convenção sobre configuração". No entanto, a realidade é que os aplicativos Spring precisam de uma certa quantidade de configuração.

Nas versões Spring 2.5.xe anteriores, o idioma comum era fornecer essa configuração via XML. Com o Spring 3.0+, a maneira idiomática é usar anotações (algo que o Java EE6 / 7 também incentiva).

Como uma observação lateral, pode ser divertido (entristecedor?) Ver uma entidade JPA anotada, é bastante fácil adicionar mais de 4 anotações a um único campo ....

<annotation-driven />

Você precisa especificar o esquema XML de onde isso vem.

Provavelmente, está no contexto da estratégia de manipulação de transações JPA ao definir o Transaction Manager (consulte 9.5.6. Usando @Transactional nos documentos da Spring)

Quando você define o gerenciamento de transações acionadas por anotações - o Spring AOP cria automaticamente aspectos para o seu método iniciar (ou verificar a existência) da transação antes da invocação de um método e, em seguida, confirmar (ou retroceder em caso de exceção) após o término da ivokation do método.

Descobri que a criação de IoC / Bean baseada em anotações é útil quando você tem uma implementação de singleton, mas pode precisar trocá-la.

Em contraste com uma situação em que você pode precisar reutilizar um bean repetidamente com diferentes classes / instâncias dependentes.

Nesses casos, declaro o bean em config e geralmente faço injeção de construtor de qualquer dependência que eu precise. Então, na classe que usará o (s) feijão (s) I @Autowiree então @Qualifier("")- é assim que as fábricas devem funcionar.

Um singleton é um método de fábrica que retorna apenas 1 resultado. Quando isso não se aplica com facilidade, é quando você precisa misturar tudo.

Quanto ao uso de varredura de componentes vs. Geralmente sou muito explícito sobre a verificação de componentes de pacotes. Dessa forma, posso criar um contexto de aplicativo diferente para teste, onde posso zombar de dependências externas (como um banco de dados) enquanto ainda tento o restante da minha configuração de IoC.

Além disso, não tenho @Componentnenhum código de biblioteca no meu projeto. Você nunca sabe quando / como precisará usar um bean e, se o utilizar @Component, poderá capturá-lo acidentalmente em uma varredura e limitar sua reutilização. Para esses casos, geralmente tenho um contexto de aplicativo definido na biblioteca com alguns padrões úteis de declaração de bean que meu projeto principal pode incluir nas importações para o contexto de aplicativo.

Nenhuma religião aqui. Apenas experiências para transmitir

O Spring oferece opções, originalmente havia apenas a fiação baseada em xml. Fiação posterior baseada em anotação foi adicionada.
Agora é possível (e muitas pessoas o fazem) usar uma mistura de ambos.
Há uma ampla documentação incluída no Spring e / ou disponível para download no site da springsource. Há treinamento profissional (nunca fiz isso, não posso garantir) e alguns bons livros (eu gosto do APress 'Pro Spring, escolha o lançamento certo para a versão do Spring que você está empregando).