Convenzione di denominazione per il contesto dell'applicazione Spring XML

Question

Sto decidendo una convenzione di denominazione per i miei file di contesto dell'applicazione Spring. Mi sono imbattuto in questo blog e un paio di tutorial che suggeriscono applicationContext-<name>.xml è la strada da percorrere. Generalmente non trovo la possibilità di mischiare il caso cammello con trattini/caratteri di sottolineatura. Quali sono alcune altre convenzioni sui nomi che hai visto?

Modifica: sto anche pensando di annidare i file di contesto all'interno del pacchetto che li riguarda. Ad esempio, le mie classi/interfacce relative all'ordinamento andrebbero nel file di contesto com/mycompany/order/spring-context.xml. Avrei un livello superiore applicationContext.xml che riunisce tutto. Suggerimenti?

Answer 1

Se ci fosse una convenzione, vorrei che fosse:

1. file memorizzati in pacchetti (non a pacchetto predefinito) per ovviare a potenziali conflitti di nomi e significa anche che non ho includere l'applicazione nome in loro, è definito dal pacchetto.
2. file denominati caso tutto inferiore con un '-' per separare i nomi

tendo ad anteporre i miei file di configurazione di primavera con la "primavera" rende più evidente ciò che essi sono utilizzati per, ma questo non è necessariamente obbligatorio.

Ma lasciatemi dire che questo funzionerebbe per il modo in cui ho trattato i miei file di primavera, potrebbe non funzionare per tutti i contesti.

IMHO applicationContext- <nome> .xml è un po 'prolisso (lungo) e mi piace tutto in minuscolo in quanto è diverso dal mio java source e (penso) li rende più facili da leggere.

Answer 2

Per un progetto Web MVC, tendo ad abbattere i vari file di contesto lungo linee di responsabilità:

• appname-dao.xml
• appname-servlet.xml
• appname-services.xml
• appname-security.xml

Answer 3

entrambi i casi Camel Case o "-" separati funzionerebbero e, fintanto che sei coerente. So che nel nostro caso non inseriamo i file di contesto nella stessa directory del codice, a meno che il codice stesso non sia in grado di riconoscere Spring, che nel nostro caso non lo è.

Abbiamo due casi per questo, dove usiamo Maven 2, il file di contesto va in una directory resource/spring, dove resource è un fratello della directory java source. Dove si usa il maven 1, semplicemente creiamo un pacchetto di root root e mettiamo il contesto lì. Entrambi questi casi assumono il codice java "normale". Nel caso dei bundle Wars, EJB e OSGi, i file risiedono in genere nella directory meta-inf.

Inoltre, non viene utilizzato un contesto applicativo di primo livello per "trascinare" tutto insieme. Creiamo semplicemente un contesto con più file di contesto. Lo troviamo molto più semplice per i test in diversi modi, test unitari con oggetti mock, test di integrazione senza server e test di integrazione completi distribuiti su un server. In tutti questi scenari, è sufficiente riconfigurare come viene creato il contesto invece di avere un contesto "principale" per ogni scenario.

Answer 4

Apprezzo molto la convenzione applicationContext-<name>.xml.

In generale <name> si riferisce al nome del modulo Maven in tutti i nostri progetti. Quindi, ogni modulo che richiede una configurazione Spring ha il proprio file applicationContext-<name>.xml. Il "modulo di esecuzione", ovvero il modulo che rappresenta il tipo di punto di ingresso nell'applicazione (WAR, EAR, ecc.) Ha un singolo applicationContext.xml che importa solo tutti i file applicationContext-<name>.xml.

Usiamo questa convenzione a livello aziendale rigorosamente in tutti i nostri progetti Maven/Spring e si è dimostrato estremamente semplice, chiaro ed efficiente.