Si encuentras algún problema con tu código o trabajo, recuerda probar siempre en un ambiente de testing antes subir el código al proyecto final.
Solución:
El trabajo del DispatcherServlet es tomar un URI entrante y encontrar la combinación correcta de controladores (generalmente métodos en Controlador clases) y vistas (generalmente JSP) que se combinan para formar la página o recurso que se supone que se encuentra en esa ubicación.
puede que tenga
- un archivo
/WEB-INF/jsp/pages/Home.jsp -
y un método en una clase
@RequestMapping(value="/pages/Home.html") private ModelMap buildHome() return somestuff;
los Servlet despachador es el bit que “sabe” llamar a ese método cuando un navegador solicita la página y combinar sus resultados con el archivo JSP correspondiente para crear un documento html.
La forma en que logra esto varía ampliamente según la configuración y la versión de Spring.
Tampoco hay ninguna razón por la que el resultado final tenga que ser páginas web. Puede hacer lo mismo para localizar RMI puntos finales, manejar JABÓN solicitudes, cualquier cosa que pueda entrar en un servlet.
En Spring MVC, todas las solicitudes entrantes pasan por un solo servlet. Este servlet – DispatcherServlet – es el controlador frontal. El controlador frontal es un patrón de diseño típico en el desarrollo de aplicaciones web. En este caso, un solo servlet recibe todas las solicitudes y las transfiere a todos los demás componentes de la aplicación.
La tarea del DispatcherServlet es enviar una solicitud al controlador Spring MVC específico.
Normalmente tenemos muchos controladores y DispatcherServlet hace referencia a uno de los siguientes mapeadores para determinar el controlador de destino:
BeanNameUrlHandlerMapping;ControllerBeanNameHandlerMapping;ControllerClassNameHandlerMapping;DefaultAnnotationHandlerMapping;SimpleUrlHandlerMapping.
Si no se realiza ninguna configuración, el DispatcherServlet usos BeanNameUrlHandlerMapping y DefaultAnnotationHandlerMapping por defecto.
Cuando se identifica el controlador de destino, el DispatcherServlet le envía una solicitud. El controlador realiza un trabajo de acuerdo con la solicitud (o lo delega a los otros objetos) y regresa al DispatcherServlet con el Modelo y el nombre de la Vista.
El nombre de la Vista es solo un nombre lógico. Este nombre lógico se utiliza luego para buscar la Vista real (para evitar el acoplamiento con el controlador y la Vista específica). Luego DispatcherServlet se refiere a ViewResolver y asigna el nombre lógico de la Vista a la implementación específica de la Vista.
Algunas posibles implementaciones del ViewResolver están:
BeanNameViewResolver;ContentNegotiatingViewResolver;FreeMarkerViewResolver;InternalResourceViewResolver;JasperReportsViewResolver;ResourceBundleViewResolver;TilesViewResolver;UrlBasedViewResolver;VelocityLayoutViewResolver;VelocityViewResolver;XmlViewResolver;XsltViewResolver.
Cuando el DispatcherServlet determina la vista que mostrará los resultados que se presentarán como respuesta.
Finalmente, el DispatcherServlet devuelve el Response objetar al cliente.
Sé que esta pregunta ya está marcada como resuelta, pero quiero agregar una imagen más nueva que explique este patrón en detalle (fuente: primavera en acción 4):
Explicación
Cuando la solicitud sale del navegador (1), contiene información sobre lo que solicita el usuario. Como mínimo, la solicitud llevará la URL solicitada. Pero también puede contener datos adicionales, como la información enviada en un formulario por el usuario.
La primera parada en los viajes de la solicitud es en DispatcherServlet de Spring. Como la mayoría de los marcos web basados en Java, Spring MVC canaliza las solicitudes a través de un único servlet de controlador frontal. Un controlador frontal es un patrón de aplicación web común en el que un solo servlet delega la responsabilidad de una solicitud a otros componentes de una aplicación para realizar el procesamiento real. En el caso de Spring MVC, DispatcherServlet es el controlador frontal. El trabajo de DispatcherServlet es enviar la solicitud a un controlador Spring MVC. Un controlador es un componente de Spring que procesa la solicitud. Pero una aplicación típica puede tener varios controladores, y DispatcherServlet necesita ayuda para decidir a qué controlador enviar la solicitud. Entonces el DispatcherServlet consulta una o más asignaciones de manejadores (2) para averiguar dónde será la próxima parada de la solicitud. El mapeo del controlador presta especial atención a la URL transportada por la solicitud al tomar su decisión. Una vez que se ha elegido un controlador apropiado, DispatcherServlet envía la solicitud en su camino alegre al controlador elegido (3). En el controlador, la solicitud deja su carga útil (la información enviada por el usuario) y espera pacientemente mientras el controlador procesa esa información. (En realidad, un controlador bien diseñado realiza poco o ningún procesamiento por sí mismo y, en su lugar, delega la responsabilidad de la lógica empresarial a uno o más objetos de servicio). La lógica realizada por un controlador a menudo da como resultado cierta información que debe llevarse de regreso a el usuario y se muestra en el navegador. Esta información se conoce como modelo. Pero enviar información sin procesar al usuario no es suficiente; debe formatearse en un formato fácil de usar, generalmente HTML. Para eso, la información debe entregarse a una vista, generalmente una página JavaServer (JSP). Una de las últimas cosas que hace un controlador es empaquetar los datos del modelo e identificar el nombre de una vista que debería representar la salida. Luego envía la solicitud, junto con el modelo y el nombre de la vista, de regreso al DispatcherServlet (4). Para que el controlador no se acople a una vista en particular, el nombre de la vista devuelto a DispatcherServlet no identifica directamente una JSP específica. Ni siquiera sugiere necesariamente que la vista sea una JSP. En cambio, solo lleva un nombre lógico que se usará para buscar la vista real que producirá el resultado. El DispatcherServlet consulta un solucionador de vistas (5) para mapear el nombre de la vista lógica a una implementación de vista específica, que puede ser o no una JSP. Ahora que DispatcherServlet sabe qué vista generará el resultado, el trabajo de la solicitud casi ha terminado. Su última parada es en la implementación de la vista. (6), normalmente una JSP, donde entrega los datos del modelo. El trabajo de la solicitud finalmente está hecho. La vista utilizará los datos del modelo para generar la salida que el objeto de respuesta (no muy trabajador) devolverá al cliente. (7).
Recuerda mostrar este artículo si te fue de ayuda.