Pourquoi utiliser les hiérarchies Spring ApplicationContext?
J'essaie de comprendre les hiérarchies ApplicationContext au printemps.
J'ai appris ce qui suit
- Un ApplicationContext ne peut pas plus de 1 parent ApplicationContext.
- quand une donnée ApplicationContext ne peut pas résoudre un bean, il transmettra la résolution demande à son parent.
- Le parent de un ApplicationContext est spécifié dans son constructeur.
Je voudrais comprendre quand utiliser les hiérarchies ApplicationContext (à la place D'une seule ApplicationContext).
Le meilleur que j'ai pu obtenir de google était this . Et ce que je comprends, c'est que si une application a un grand nombre de beans définis aux différentes couches, chaque couche ayant son propre ApplicationContext serait un avantage. Ce n'est pas compris, c'est quel est l'avantage de le faire et comment le bénéfice ainsi réalisé?
TIA, Vijay
1 réponses
Le cas d'utilisation classique pour cela est lorsque vous avez plusieurs Spring DispatcherServlet dans une seule webapp, avec chacun de ces servlets ayant leur propre contexte d'application, mais qui ont besoin de partager des beans entre eux. Dans ce cas, vous ajoutez un 3ème contexte au niveau de l'application web, qui est le parent de chacun des servlet appcontexts.
Vous pouvez prendre ce modèle plus loin, par exemple si vous avez plusieurs webapps regroupés dans une seule oreille JavaEE. Ici, l'OREILLE peut avoir son propre contexte, qui est le parent des contextes webapp individuels, qui est le parent des contextes de servlet, et ainsi de suite. Vous avez cette hiérarchie de responsabilité.
Dans d'autres situations, la structure du contexte est dictée par un autre facteur. Par exemple, Spring Security est indépendant de Spring MVC, et nécessite ses beans de configuration pour aller dans le contexte webapp. Si vous voulez utiliser Spring MVC avec, alors la configuration pour cela doit aller dans le contexte de servlet, qui a le contexte webapp racine comme son parent.