examples - Entendiendo los contextos en Spring MVC
spring mvc examples (2)
Soy nuevo en Spring y estoy creando una aplicación web simple. He estado leyendo sobre contextos en Spring MVC.
Estoy usando el plugin STS para eclipse. Creé un proyecto Spring MVC usando el complemento.
Ahora tengo tres documentos XML en el proyecto, web.xml, root-context.xml y servlet-context.xml. Estos fueron creados por STS para mí.
En web.xml, el servlet de dispatcher apunta hacia servlet-context.xml y entiendo que el trabajo de servlets de dispatcher es crear un contexto de aplicación web que sepa cómo resolver vistas y es un lugar para que existan beans de controlador. ¿Mi entendimiento es correcto? Si es así, ¿qué otro trabajo se lleva a cabo en este contexto?
Ahora, hay un archivo llamado root-context.xml que tiene una exploración de componentes en el paquete predeterminado de mis proyectos. Mi entendimiento es que este contexto necesita tener beans globales que muchos servlets podrían usar. ¿Mi entendimiento es correcto? ¿Qué más hace esto? ¿Qué tipo de contexto se crea utilizando este archivo?
Ahora, estoy más avanzado en el proyecto y tengo varios archivos * -context.xml (dao-context.xml, security-context.xml, etc.) que se cargan utilizando contextLoaderListner (en web.xml). ¿Es esta una buena idea? ¿O todo debería ir a servlet-context.xml? Creo que es una buena idea tener diferentes contextos ya que proporciona una separación de preocupaciones. ¿Comentarios? Además, ¿qué tipo de contexto se crea a partir de estos archivos * -context.xml? ¿Cuál es la ubicación correcta de la carpeta para estos archivos?
Web.xml es para el contenedor de servlets como Tomcat, etc., y todos los demás archivos XML del proyecto son para el contenedor de Spring. ¿Es eso correcto? ¿Todos estos archivos están separados para proporcionar una separación de preocupación?
¿Cuántos contextos de aplicación y contextos de aplicación web existen en el escenario actual?
¿Por qué alguien necesitaría más de un servlet de despachador?
¿Por qué alguien necesitaría más de un contexto de aplicación?
¿Pensamientos? ¿Comentarios? Correcciones? ¿Mejores prácticas?
Bueno, Spring no te obliga a tener archivos xml de esa manera, puedes trabajar todo bien usando solo un archivo xml que sea servlet-context.xml y usando solo un servlet de despachador. Por lo general, existen diferentes archivos para definir los beans de servicio o los dao beans, por lo que esto depende básicamente del diseño de la aplicación, por ejemplo, si está utilizando la seguridad Spring, es posible que desee agregar un archivo xml más como security-context.xml como Como dije, depende del diseño. En realidad, puede eliminar el escucha del cargador de contexto por completo y aún así lograr hacer todo con el servlet de dispatcher. Su pregunta es demasiado amplia en cuanto a su alcance, ya que es nuevo en primavera, por lo que debería obtener más detalles sobre los contenedores de resortes y decidir qué se adapta a sus necesidades. Por lo general, tengo mi servlet-context.xml en WEB-INF y otra configuración como service-context.xml en classpath, una vez más, esto no es una regla estricta como me conviene.
La idea detrás de este diseño es manejar diferentes capas arquitectónicas en una aplicación web típica y proporcionar un mecanismo de herencia / reemplazo para los beans en todos los contextos. Cada tipo de contexto en Spring está relacionado con una capa arquitectónica diferente, por ejemplo, capa web, capa de servicio, etc.
Una aplicación web basada en Spring puede tener varios servlets de dispatcher configurados (aunque en la mayoría de los casos es un solo servlet, pero dispatcher serlvet es un servlet y podría haber múltiples configurados en web.xml). Estos se pueden configurar para manejar diferentes patrones de url. Obviamente, cada uno es un servlet diferente y, por lo tanto, puede tener un contexto de aplicación web Spring diferente. Cada uno de estos puede contener diferentes configuraciones para la capa web de Spring, como controladores, interceptores, resoluciones de vista, resolución de locale, etc., ya que estos suelen pertenecer a la capa web de una aplicación. Todas estas configuraciones y beans son privados para cada servlet de despachador, por lo que no son visibles entre sí. Por lo tanto, tener un contexto de aplicación web de Spring separado tiene sentido para habilitar esta privacidad. Sin embargo, hay otros beans que están diseñados para ser compartidos, por lo tanto, pertenecen a un contexto raíz. Por lo tanto, todas las cosas que se pueden compartir pertenecen al contexto raíz y pueden considerarse globales para esta aplicación web.
Cada servlet de distribuidor hereda todos los beans definidos en el contexto raíz. Sin embargo, el punto importante a tener en cuenta es que los beans compartidos pueden ser reemplazados por los respectivos beans específicos del servlet del despachador. Por lo tanto, en las aplicaciones web, el contexto de la raíz se puede ver como algo que se hereda pero se puede anular.