Comprensione dei contesti in Spring MVC

Question

Sono nuovo per la primavera e sto creando una semplice applicazione web. Ho letto dei contesti in Spring MVC.

Sto usando il plugin STS per Eclipse. Ho creato un progetto MVC Spring usando il plugin.

Ora ho tre documenti xml nel progetto, web.xml, root-context.xml e servlet-context.xml. Questi sono stati creati da STS per me.

1. In web.xml, servlet dispatcher è puntato verso servlet-context.xml e capisco il lavoro servlet dispatcher è di creare un contesto di applicazione web che sa come risolvere i punti di vista e 'un posto per i fagioli del controller a esistere. La mia comprensione è corretta? In tal caso, quale altro lavoro viene svolto da questo contesto?

2. Ora, c'è un file chiamato root-context.xml che ha una scansione dei componenti sul pacchetto predefinito dei miei progetti. La mia comprensione è che questo contesto ha bisogno di avere bean globali che molti servlet potrebbero usare. La mia comprensione è corretta? Che altro fa questo? Che tipo di contesto viene creato utilizzando questo file?

3. Ora, io sono più avanti nel progetto e ho diversi file -context.xml * (dao-context.xml, la sicurezza-context.xml ecc) che vengono caricati utilizzando contextLoaderListner (in web.xml). E 'questa una buona idea? O tutto dovrebbe andare in servlet-context.xml? Penso che sia una buona idea avere contesti diversi in quanto fornisce la separazione delle preoccupazioni. Commenti? Inoltre, che tipo di contesto viene creato da questi file * -context.xml? Qual è l'ubicazione corretta della cartella per questi file?

4. Web.xml è per il contenitore servlet come tomcat ecc e tutti gli altri file xml nel progetto sono per il contenitore a molla. È corretto? Tutti questi file sono separati per fornire separazione delle preoccupazioni?

5. Quanti contesti applicativi e contesti di applicazioni Web esistono nello scenario corrente?

Perché qualcuno dovrebbe aver bisogno di più di un servlet di dispatcher?

Perché qualcuno avrebbe bisogno di più di un contesto applicativo?

Pensieri? Commenti? Correzioni? Migliori pratiche?

Answer 1

L'idea alla base di questo progetto consiste nel gestire diversi livelli architettonici in una tipica applicazione Web e fornire meccanismi di ereditarietà/sovrascrittura per i bean in tutti i contesti.Ogni tipo di contesto in Primavera è correlato a diversi livelli architetturali per esempio, livello Web, livello servizio, ecc.

Un'applicazione Web basata sulla molla può avere configurato più servlet di dispatcher (sebbene nella maggior parte dei casi sia un singolo servlet - ma dispatcher serlvet è comunque un servlet e potrebbero essere configurati multipli in web.xml). Questi possono essere configurati per gestire diversi pattern di URL. Quindi ovviamente ognuno di essi è un servlet differente e quindi può avere un contesto di applicazione Web Spring diverso. Ognuno di questi può contenere diverse configurazioni per il web layer di Spring come controller, interceptor, resolver di visualizzazione, resolver di localizzazione ecc. In quanto questi di solito appartengono al livello web di un'applicazione. Tutte queste configurazioni e i bean sono privati ​​per ogni servlet del dispatcher in modo che non siano visibili l'uno con l'altro. Quindi avere un contesto separato per le applicazioni web di primavera ha senso per abilitare questa privacy. Tuttavia ci sono altri bean che sono progettati per essere condivisi quindi appartengono a un contesto di root. Quindi tutte le cose condivisibili appartengono al contesto di root e possono essere considerate globali per questa applicazione web.

Ogni servlet dispatcher eredita tutti i bean definiti nel contesto radice. Tuttavia, il punto importante da notare è che i bean condivisi possono essere sovrascritti dai rispettivi bean specifici del servlet del dispatcher. Quindi, nelle applicazioni Web, il contesto di root può essere visto come qualcosa che è ereditato ma può essere sovrascritto.

Answer 2

Ben molla non ti obbliga ad avere file xml in questo modo, puoi benissimo lavorare tutto usando un solo file xml che sarebbe servlet-context.xml e usando solo il servlet dispatcher. Generalmente ci sono diversi file per definire i tuoi bean di servizio o dao bean, quindi questo dipende fondamentalmente dalla progettazione dell'applicazione, per esempio se stai usando la sicurezza di primavera potresti voler aggiungere un altro file xml come security-context.xml come come ho detto dipende dal design. È possibile eliminare completamente il listener del caricatore di contesto e continuare a eseguire tutto utilizzando il servlet di dispatcher. La tua domanda è troppo ampia, dato che sei nuovo per la primavera, dovresti ottenere maggiori dettagli sui contenitori a molla e decidere cosa si adatta alle tue esigenze. Generalmente ho il mio servlet-context.xml in WEB-INF e altre configurazioni come service-context.xml in classpath, ancora una volta non è una regola rigida quanto mi si addice.