Quando non usare Spring per creare un'istanza di un bean?

Sto cercando di capire quale sarebbe l'uso corretto di Spring. Non sintatticamente, ma in termini di scopo. Se si utilizza Spring, il codice Spring dovrebbe sostituire tutto il codice di istanza del bean? Quando usare o quando non usare Spring, per creare un'istanza di un bean?

Potrebbe essere il seguente esempio di codice che ti aiuterà a capire il mio dilemma:

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

Se configuro Spring, diventa qualcosa del tipo:

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

Personalmente penso che usare Spring qui sia un sovraccarico inutile, perché

1. Il codice è più semplice da leggere / comprendere.
2. Non è davvero un buon posto per Dependency Injection poiché non mi aspetto che ci sarà un'implementazione multipla / variata ClassA, che vorrei sostituire liberamente usando la configurazione di Spring in un secondo momento.

Sto pensando correttamente? In caso contrario, dove sbaglio?

Hai ragione, Spring non è appropriata per il caso d'uso elencato. Spring è meglio utilizzato per gestire dipendenze esterne (come collegare una connessione JDBC a un DAO) o configurazioni (come specificare quale tipo di database usare). Nel tuo esempio, se il tipo di bean dovesse cambiare, allora useresti un'interfaccia per specificare il bean e creare un'istanza dei bean usando Factory. Utilizzeresti Spring per specificare quale factory utilizzare e iniettarlo nella classe che era necessaria per istanziare i bean. Potresti quindi avere diverse fabbriche diverse che hanno creato diversi tipi di bean (che supportano tutti l'interfaccia del bean) e configurano quella appropriata al momento dell'installazione (o dell'aggiornamento).

Userei Spring (o un altro sistema DI) tra i layer, istanziazione diretta all'interno dei layer.
Quindi una classe che crea un bean che lascia l'ambito di quella classe, a un sistema (funzionalmente) esterno, eventualmente definito da quel sistema o da un livello di comunicazione, verrebbe creato tramite DI. Un altro bean creato esclusivamente per uso interno all'interno del livello dell'applicazione viene creato direttamente, sia per motivi di chiarezza del codice che per motivi di prestazioni (anche in sistemi di grandi dimensioni).

Se è un bean , dovresti lasciare che Spring lo costruisca (tranne che puoi fornire un bean factory - l'ho usato dove dovevo restituire una sottoclasse specifica dipendente da una proprietà di sistema - e dovresti consultare la documentazione sul@Configuration@Bean annotazioni e se lo stai facendo). Se non è un bean, ma piuttosto un semplice oggetto Java semplice, non è necessario utilizzare Spring per crearlo. I POJO sono utili, ma non riceveranno l'iniezione di dipendenza, i wrapper AOP, ecc. Poiché queste sono le cose che Spring aggiunge per te.

La decisione fondamentale è se si tratta davvero di un bean o di un semplice oggetto che segue alcune convenzioni di bean (ad esempio, la denominazione del metodo). Non riesco a immaginare quale sia il caso del piccolo esempio che hai dato.

Potrei essere degli esperti sbagliati, per favore, correggi.

L'intero concetto di Bean nel contesto primaverile è che Spring Container si prenda cura dell'oggetto. È la nascita è la morte del ciclo di vita dell'ambito ecc ... È come se fosse un custode dell'oggetto. L'applicazione che ne ha bisogno lo inietta.

Quindi, mentre prendi una decisione durante la progettazione del tuo modulo, pensa sempre se vuoi che il framework Spring si prenda cura o sia un semplice oggetto il cui ciclo di vita è racchiuso in un metodo.

Come precedentemente suggerito, gli oggetti dao jms code oggetti, ecc. Sono pesanti e meglio lasciati all'esperto che è il framework Spring per occuparsene.