Comprensione dei contesti in Spring MVC

Sono nuovo per la spring 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 Spring MVC 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, il servlet del dispatcher è puntato verso servlet-context.xml e capisco che il lavoro dei servlet del dispatcher è quello di creare un contesto di applicazione Web che sappia come risolvere le viste ed è un posto in cui i bean controller possano 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, sono più avanti nel progetto e ho diversi file * -context.xml (dao-context.xml, security-context.xml etc) che vengono caricati usando 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 spring. È 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 dovrebbe aver bisogno di più di un contesto applicativo?

Pensieri? Commenti? Correzioni? Migliori pratiche?

L’idea alla base di questo progetto è quella di gestire diversi livelli architettonici in una tipica applicazione Web e fornire meccanismi di ereditarietà / override per i bean in tutti i contesti. Ogni tipo di contesto in spring è correlato a diversi livelli architettonici per es. Livello web, livello di servizio, ecc.

Un’applicazione Web basata su Spring può avere configurato un servlet di dispatcher multiplo (sebbene nella maggior parte dei casi si tratti di un singolo servlet, ma il dispatcher serlvet è comunque un servlet e potrebbero essere configurati più 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 spring 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 di dispatcher eredita tutti i bean definiti nel contesto di root. 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.

Beh, la spring non ti obbliga ad avere file xml in questo modo, puoi benissimo lavorare su 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 propri bean di servizio o dao bean, quindi questo dipende fondamentalmente dalla progettazione dell’applicazione, per esempio se si utilizza la sicurezza di spring si potrebbe voler aggiungere un altro file xml come security-context.xml come come ho detto dipende dal design. È ansible 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 spring potrebbe essere necessario 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 come mi si addice.