Primavera: confusione sulla configurazione?

Da qualche parte che ho letto Spring offre convenienza rispetto alla configurazione. Ma la gente di Spring sta apportando così tanti cambiamenti sulla configurazione, che ora mi sto davvero confondendo nell'usare la configurazione xml o l'annotazione.

Vorrei che qualcuno suggerisse una metodologia infallibile o una regola empirica nell'uso di xml e annotazioni.

Esempi in SO per mostrare che molti principianti come me si stanno confondendo sulla configurazione.

• link-1

  Non sembra cogliere la funzionalità dietro <context:annotation-config>e <context:component-scan>.

  Da quello che ho letto sembrano gestire diverse annotazioni (@Required, @Autowired etc vs @Component, @Repository, @Service ecc.) Ma anche da quello che ho letto registrano le stesse classi di post processor del bean.

  Per confondermi ancora di più, c'è un annotation-configattributo su <context:component-scan>...

• collegamento 2

  Ho ancora il tag di scansione del componente:

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

  ma ho anche un altro tag (che sembra avere un compito simile), questo:

  <annotation-driven />

  Qual è la differenza tra questi due tag? Un'altra cosa "strana" è che l'esempio precedente (che non utilizza il tag basato sulle annotazioni) è molto simile al progetto creato da STS usando il progetto Spring MVC Template ma se elimino il tag basato sulle annotazioni dalla sua configurazione file il progetto non viene eseguito e mi dà il seguente errore: HTTP Status 404 - ...

Spring 3.2 non ha più bisogno di cglib per il proxy, ma le versioni inferiori usano cglib. Una citazione dal blog di springsource

Per generare tali proxy, Spring utilizza una libreria di terze parti chiamata cglib. Sfortunatamente, questo progetto non è più attivo. Nella primavera 3.2, è molto probabile che la primavera userà Javassist invece di default.

Sono sufficienti per suggerire che Spring è Confusione sulla configurazione?

Spring mira a fornire un framework in cui esiste 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, il linguaggio comune era fornire questa configurazione tramite XML. Con Spring 3.0+, il modo idiomatico è usare le annotazioni (cosa che anche Java EE6 / 7 incoraggia).

Come nota a margine, può essere divertente (rattristante?) Vedere un'entità JPA con annotazioni, è piuttosto facile aggiungere 4+ annotazioni in un singolo campo ....

<annotation-driven />

Devi specificare lo schema XML da dove proviene.

Molto probabilmente è nel contesto della strategia di gestione delle transazioni JPA durante la definizione di Transaction Manager (vedere 9.5.6. Uso di @Transactional nei documenti di Spring)

Quando si definisce la gestione delle transazioni basata sulle annotazioni, Spring AOP crea automagicamente aspetti affinché il metodo inizi (o controlli la presenza) della transazione prima dell'invocazione di un metodo e quindi esegua il commit (o il rollback in caso di eccezione) dopo la fine del metodo ivokation.

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

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

In questi casi dichiaro il bean in config e di solito faccio l'iniezione da parte del costruttore di qualsiasi dipendenza di cui abbia bisogno. Quindi, nella classe che utilizzerà detti bean I @Autowiree quindi @Qualifier("")- è così che le fabbriche dovrebbero funzionare.

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

Per quanto riguarda l'utilizzo di component-scan vs. not this, questo è veramente soggetto ai criteri di cui sopra e buon senso. In genere sono molto esplicito sulla scansione dei componenti del pacchetto. In questo modo posso creare un contesto applicativo diverso per i test in cui posso prendere in giro dipendenze esterne (come un db) mentre collaudo ancora il resto della mia configurazione IoC.

Inoltre, non ho @Componentalcun codice di libreria nel mio progetto. Non si sa mai quando / come sarà necessario utilizzare un bean in esso e @Component, in tal caso, è possibile prenderlo accidentalmente in una scansione e limitarne la riusabilità. Per questi casi generalmente ho un contesto applicativo definito nella libreria con alcuni pratici valori predefiniti di dichiarazione bean che il mio progetto principale PUO 'includere con le importazioni nel suo contesto applicativo.

Nessuna religione qui. Solo esperienze da trasmettere

La primavera offre opzioni, originariamente c'era solo il cablaggio basato su XML. Successivamente è stato aggiunto un cablaggio basato su annotazioni.
Ora è possibile (e molte persone lo fanno) usare un mix di entrambi.
Vi è un'ampia documentazione inclusa con Spring e / o scaricabile dal sito Web di Springsource. C'è un addestramento professionale (mai fatto, non posso garantirlo), e alcuni buoni libri (mi piace APress 'Pro Spring, scegli la versione giusta per la versione di Spring che stai impiegando).