Spring - Confusione sulla configurazione?

La primavera ha lo scopo di fornire una struttura in cui vi è una "convenzione sulla configurazione". Tuttavia, la realtà è che le applicazioni Spring hanno bisogno di una certa quantità di configurazione.

Nella primavera 2.5.xe versioni precedenti, l'idioma comune era di fornire questa configurazione via XML. Con Spring 3.0+, il modo più idiomatico è usare le annotazioni (qualcosa che anche Java EE6 / 7 incoraggia).

Come nota a margine, può essere divertente (rattristarsi?) vedere un'entità JPA annotata, è piuttosto facile aggiungere 4+ annotazioni a un singolo campo ....

<annotation-driven />

Devi specificare lo schema XML da dove proviene.

Molto probabilmente è nel contesto della strategia di gestione delle transazioni JPA quando si definisce il gestore delle transazioni (si veda 9.5.6 Utilizzo di @Transactional nei documenti di Spring)

Quando si definisce la gestione della transazione basata sull'annotazione - Spring AOP crea automaticamente aspetti per il proprio metodo di iniziare (o verificare la presenza) prima del richiamo di un metodo e poi commit (o rollback in caso di eccezione) dopo il metodo ivokation è finito.

Ho trovato che la creazione di IoC / Bean basata su annotazioni è utile quando si ha un'implementazione singleton, ma potrebbe essere necessario sostituirla.

In contrasto con una situazione in cui potrebbe essere necessario riutilizzare un bean ripetutamente con diverse classi / istanze dipendenti.

In questi casi dichiaro il bean in config e di solito faccio l'iniezione del costruttore di qualunque dipendenza di cui ho bisogno. Quindi, nella classe che userà detto bean (s) I @Autowire e poi @Qualifier("") - è così che le fabbriche dovrebbero funzionare.

Un singleton è un metodo factory che restituisce solo 1 risultato. Quando questo non si applica facilmente è quando devi mescolarlo.

Per quanto riguarda l'uso di Scansione componenti vs. non ciò è realmente soggetto ai criteri sopra riportati e al buon senso. In genere sono molto esplicito riguardo alla scansione dei componenti del pacchetto. In questo modo posso creare un contesto applicativo diverso per testare dove posso prendere in giro le dipendenze esterne (come un db) mentre sto ancora testando il resto della mia configurazione IoC.

Inoltre, non aggiungo @Component a nessun codice di libreria nel mio progetto. Non si sa mai quando / come sarà necessario utilizzare un bean e se si @Component esso, si potrebbe accidentalmente raccoglierlo in una scansione e si limita la sua riusabilità. Per questi casi generalmente ho definito un contesto applicativo nella libreria con alcuni pratici valori predefiniti di dichiarazione del bean che il mio progetto principale PUO includere nelle importazioni nel suo contesto applicativo.

Nessuna religione qui. Solo esperienze da trasmettere

Opzioni di offerte di primavera, in origine c'era solo il cablaggio basato su xml. È stato aggiunto il cablaggio basato sull'annotazione successiva.
Ora è possibile (e molte persone lo fanno) utilizzare un mix di entrambi.
C'è un'ampia documentazione inclusa con Spring e / o scaricabile dal sito di Spring Source. C'è un allenamento professionale (mai fatto, non posso garantire per questo), e alcuni buoni libri (mi piace APress 'Pro Spring, scegli la versione giusta per la versione di Spring che stai impiegando).