Quando não usar o Spring para instanciar um bean?

Estou tentando entender qual seria o uso correto do Spring. Não sintaticamente, mas em termos de sua finalidade. Se alguém estiver usando o Spring, o código do Spring deve substituir todo o código de instanciação do bean? Quando usar ou quando não usar o Spring, para instanciar um bean?

Pode ser que o seguinte exemplo de código o ajude a entender meu dilema:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = new ClassA();
    ca.setName(name);
    caList.add(ca);
}

Se eu configurar o Spring, ele se tornará algo como:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = (ClassA)SomeContext.getBean(BeanLookupConstants.CLASS_A);
    ca.setName(name);
    caList.add(ca);
}

Pessoalmente, acho que usar o Spring aqui é uma sobrecarga desnecessária, porque

1. O código é o mais simples de ler / entender.
2. Não é realmente um bom lugar para injeção de dependência, pois não estou esperando que haja uma implementação múltipla / variada ClassA, da qual gostaria de ter liberdade para substituir o uso da configuração do Spring posteriormente.

Estou pensando correto? Se não, onde estou errado?

Você está certo, o Spring é inadequado para o caso de uso que você listou. O Spring é melhor usado para gerenciar dependências externas (como conectar uma conexão JDBC a um DAO) ou configurações (como especificar qual tipo de banco de dados usar). No seu exemplo, se o tipo de bean puder ser alterado, use uma interface para especificar o bean e instanciar os beans usando um Factory. Você usaria o Spring para especificar qual fábrica usar e injetaria isso na classe necessária para instanciar os beans. Você poderia ter várias fábricas diferentes que criaram vários tipos diferentes de beans (todos suportados pela interface do bean) e configurar o apropriado no momento da instalação (ou atualização).

Eu usaria Spring (ou outro sistema DI) entre as camadas, instanciação direta dentro das camadas.
Portanto, uma classe que cria um bean que deixa o escopo dessa classe para algum sistema externo (funcionalmente), possivelmente definido por esse sistema ou alguma camada de comunicação, seria criada por meio do DI. Outro bean criado puramente para uso interno na camada de aplicativo é criado diretamente, por razões de clareza de código e (em grandes sistemas tão importantes quanto) por desempenho.

Se for um bean , você deve deixar o Spring construí-lo (exceto que você pode fornecer um bean de fábrica - usei aquele onde eu precisava retornar uma subclasse específica dependente de uma propriedade do sistema - e você deve consultar a documentação @Configuratione as @Beananotações se você estiver fazendo isso). Se não é um bean, mas apenas um Objeto Java Antigo Simples, você não precisa usar o Spring para fazê-lo. Os POJOs são úteis, mas não recebem injeção de dependência, invólucros de AOP, etc., pois essas são as coisas que o Spring adiciona para você.

A decisão fundamental é se é realmente um bean ou apenas algum objeto comum que segue algumas convenções de beans (por exemplo, nomeação de métodos). Não posso adivinhar qual é realmente o caso do pequeno exemplo que você deu.

Eu posso ser um especialista errado, corrija.

Todo o conceito de Bean no contexto da primavera é Spring Container está cuidando do objeto. É nascimento, é escopo da morte do ciclo de vida, etc ... É como se fosse um cuidador do objeto. A aplicação que precisa injeta.

Portanto, ao tomar uma decisão durante o design do seu módulo, pense sempre se você deseja que a estrutura Spring tome cuidado ou se é um objeto simples cujo ciclo de vida está incluído em um método.

Como sugerido anteriormente, os objetos dao, o jms enfileira os objetos, etc, são pesados ​​e melhor deixar para o especialista que é o framework Spring para cuidar dele.