Java: è buona pratica definire i bean in XML?

Question

In un progetto a cui sto lavorando, che sta usando Spring, vedo qualcosa che mi fa davvero impazzire. A quanto pare ci sono test di unità che hanno bisogno di lavorare e fagioli quei fagioli vengono creati dal file XML, che contiene cose come:

<bean class="...ListDTO"> 
<constructor-arg> 
    <map> 
    <entry key="use1key"> 
    <value>use1value</value> 
    </entry> 
    <entry key="use2key"> 
    <value>use2value</value> 
    </entry> 
    </map> 
</constructor-arg> 
<constructor-arg> 
    <map> 
    <entry key="nature1key"> 
    <value>nature1value</value> 
    </entry> 
    <entry key="nature2key"> 
    <value>nature2value</value> 
    </entry> 
    </map> 
</constructor-arg> 
<constructor-arg> 
    <value>false</value> 
</constructor-arg> 
</bean> 

E che cosa è accaduto? Il costruttore della classe ... ListDTO è cambiato e quindi il bean apparentemente non può più essere creato da questo XML molto dettagliato.

Qualcuno può spiegarmi perché è buona pratica (è davvero?) Mettere tale cosa in un codice XML anziché in Java? Se fosse nel codice Java, non appena il ... ListDTO avrebbe cambiato il test dell'unità, si sarebbe rifiutato di compilare (anche se la parte del test dell'unità che creasse l'istanza del bean non fosse stata eseguita [per qualsiasi ragione]).

Domanda bonus: c'è un modo per trovare facilmente tutti questi "chicchi in XML" danneggiati in un progetto oltre a eseguire tutti i test unitari, vedere quali falliscono e quindi risciacquare e ripetere?

Per me sembra un problema piuttosto serio che è possibile modificare un costruttore e che l'IDE si comporterebbe come se tutto fosse a posto: qual è la giustificazione per questo? (*)

Answer 1

L'idea alla base di questo è di mantenere le cose che differiscono tra gli ambienti (sviluppo, test, produzione) in un file di configurazione XML centrale e, utilizzando un diverso file di configurazione, si cambia ambiente.

Tuttavia, non è consigliabile utilizzare la configurazione del bean per definire strutture di dati di test complesse. Qualcuno probabilmente lo ha fatto mentre era appena innamorato dell'iniezione di dipendenza, solo perché è possibile.

Answer 2

Domanda bonus: esiste un modo per trovare facilmente tutti questi "bean in XML" danneggiati in un progetto oltre a eseguire tutti i test unitari, vedere quali falliscono e quindi risciacquare e ripetere?

Spring Tool Suite o il plug-in Spring per Eclipse possono verificare che un file di configurazione di primavera sia corretto (ha tutti i parametri di costruzione e non usa setter non individuati).

Answer 3

Penso che dovresti usare gli strumenti SpringSource quando lavori con Spring. È possibile scaricarlo sia come stand-alone o come Eclipse plugin:

http://www.springsource.com/developer/sts

http://dist.springsource.com/milestone/TOOLS/update/e3.6