La pregunta es por qué Spring integra Springmvc, entonces, ¿por qué no usar Spring + Mybatis directamente, sino usar ssm?

El siguiente contenido proviene de Internet, léalo atentamente.

Spring es un contenedor liviano, su núcleo es una fábrica de Bean, que se utiliza para construir el M (modelo) que necesitamos. Sobre esta base, Spring proporciona la implementación de AOP (programación orientada a aspectos) para proporcionar transacciones, seguridad y otros servicios en un entorno no administrado. La extensión de ApplicationContext a Bean Factory nos facilita la implementación de aplicaciones J2EE. La implementación de DAO/ORM facilita el desarrollo de nuestra base de datos. Web MVC y Spring Web proporcionan un marco para aplicaciones web Java o se integran con otros marcos web populares.

1) Marco de código abierto

2) IoC (Inversión de control), escriba la creación y las dependencias de clases en el archivo de configuración e inyéctelas en el archivo de configuración para lograr un acoplamiento flexible .

3) AOP extrae funciones relativamente independientes de seguridad y transacciones que son equivalentes a la lógica del programa, y ​​utiliza archivos de configuración Spring para insertar estas funciones, realizando programación basada en aspectos y mejorando la reutilización.

Prefacio

Recientemente leí el código fuente de Spring MVC y escribí mi comprensión del patrón MVC y la implementación de varios marcos para que todos lo vean, lo cual es un resumen. Así que les imploro a todos que vean este artículo con escepticismo. Si hay algún problema, indíquelo.

Aplicaciones MVC y WEB

No necesito decir más sobre qué es MVC. En lo que respecta al marco maduro Modelo-Vista-Control (MVC), sus principales preocupaciones no son más que los siguientes puntos:

Modelo:

El modelo debe contener la vista. mostrar datos. En las aplicaciones web J2EE, los datos normalmente deberían consistir en javabeans comunes. Una vez que el controlador selecciona una vista, el modelo debe contener datos correspondientes a esa vista. El modelo en sí no debería tener más acceso a los datos ni debería estar asociado con objetos comerciales.

Los problemas que debe resolver este modelo incluyen:

lEncapsular los datos que se mostrarán

No creo que el modelo dependa de un marco específico

l no es necesariamente un javabean

Vista:

La vista es responsable de mostrar la información contenida en el modelo. La vista no necesita conocer la información específica. implementación del controlador o del objeto comercial subyacente.

Los problemas que esta vista debe resolver incluyen:

lMostrar contenido utilizando el modelo de datos mostrado.

No debería incluir lógica empresarial.

Es posible que necesites realizar una lógica de visualización, como mostrar las filas de una matriz en colores alternos.

Es mejor que la vista L no maneje errores de validación, la validación de datos debe ser completada por otros componentes.

lLas vistas no deben manejar parámetros, los parámetros deben ser manejados centralmente por el controlador.

Control:

El controlador es como el sistema nervioso central en MVC. Es posible que necesite algunas ayudas, como analizar vistas y parámetros. Es muy importante que el controlador pueda acceder al objeto comercial o su proxy, como Action en Struts.

Los problemas a resolver por el controlador incluyen:

l Verificar y extraer los parámetros de la solicitud

l Llamar al objeto de negocio y pasar los parámetros obtenidos del pedido.

lCree un modelo y la vista mostrará el modelo correspondiente.

lElija una vista adecuada y envíela al cliente.

lA veces hay más de un controlador.

Marcos existentes

Ahora existen muchos marcos MVC. Struts y Webwork son los más populares.

Strut

Este es el framework web más popular y casi se ha convertido en un estándar de facto de la industria. Además de las ventajas que el patrón MVC debería haber comentado anteriormente, también tiene las siguientes desventajas:

lCada acción sólo se genera una vez y luego se almacena en caché.

Cuando se solicita esta acción nuevamente, no se generará ningún objeto nuevo, pero el objeto generado la primera vez se reutilizará, lo que significa que cada acción debe ser segura para subprocesos.

l Utilice ActionForm para encapsular datos del formulario, pero solo puede corresponder a datos de cadena. Aunque se puede convertir utilizando la herramienta Commons Beanutils, solo proporciona soporte a nivel de objeto.

l Depende en gran medida de la API de Servlet y es difícil de probar (pero la firma del método Action.execute en la próxima versión de Struts se cambiará a Ejecutar (Contexto de acción), por lo que es posible que la dependencia no ser tan serio).

Las reglas de verificación del marco L en sí son relativamente simples y generalmente se basan en Commons Validation para la verificación.

lEs difícil realizar algún procesamiento antes y después de la acción. A veces incluso tengo que escribir yo mismo un controlador especial.

lDebido a que Struts es una herencia de clase concreta, ¿es fácil romper la encapsulación?

Proporciono varias etiquetas personalizadas, pero el enlace de datos es demasiado primitivo, lo que hace que el código de la página dependa de Struts. Esto no es una especificación y creo que es fatal.

l Está demasiado orientado a JSP. Aunque se pueden utilizar otras tecnologías de visualización, no es muy cómodo de usar.

Estructura de red

Aunque no he utilizado este framework, he estado siguiendo su desarrollo.

Las ideas de diseño de Webwork son más inteligentes que las de Struts y, desde una perspectiva técnica, son mucho más altas que Struts. Se basa en el modo de comando y se divide en Xwork y Webwork. El marco no depende de la API de Servlet.

Xwork proporciona muchas funciones principales: interceptores, validación de formularios en tiempo de ejecución, conversión de tipos, contenedor IoC, etc.

WebWork se basa en Xwork y se utiliza para manejar respuestas y solicitudes basadas en HTTP. Las sesiones, aplicaciones y otros objetos de Servlet se encapsulan con Maps y ActionContexts para desacoplarlos de la API de Servlet.

Pero aún no es perfecto:

Crear una acción para cada solicitud puede ser un desperdicio (pero el motor Servlet también crea múltiples objetos para cada solicitud, pero no hay ningún impacto visible en el rendimiento). ¿Qué impacto tiene?

lCuando el proyecto crece, el archivo de configuración puede volverse complicado. No parece admitir múltiples perfiles.

lEl manejo de excepciones es un problema digno de mención en el modo comando: no sabemos qué excepciones específicas puede generar un comando específico, por lo que ejecutar() se ve obligado a generar excepciones independientemente de estas excepciones. ¿Es una excepción de tiempo de ejecución o una excepción marcada.

Los objetivos del marco Spring MVC

Lo anterior mencionó algunos principios de MVC, así como algunos problemas de los marcos principales actuales. Ahora veamos cómo lo maneja Spring. El marco Spring MVC define muchas interfaces basadas en diferentes roles, pero su mayor problema es también su dependencia de la API de Servlet.

El framework Spring MVC tiene algunas características:

Se basa en tecnología de componentes. Todos los objetos de la aplicación, ya sean controladores y vistas u objetos comerciales, son componentes de Java y están estrechamente integrados con otra infraestructura proporcionada por Spring.

No depende de la API de Servlet (aunque el objetivo es este, sí depende de Servlets para su implementación)

Puede utilizar cualquier tecnología de visualización, no solo JSP.

l Admite varias estrategias de mapeo para los recursos solicitados.

Debe ser fácilmente extensible.

Creo que debería haber varios principios para evaluar un marco.

lDebería ser fácil de usar y probar

¿Es Spring fácil de usar? No lo creo, especialmente su archivo de configuración. En el peor de los casos, es posible que varias infraestructuras y lógica empresarial se compriman en un único archivo de configuración. La infraestructura, como el procesamiento de transacciones, debe ser administrada por contenedores en lugar de desarrolladores. Aunque están divididos en varios archivos de configuración, la lógica es clara, pero las configuraciones básicas están expuestas.

¿Es fácil hacer el examen en primavera? Probar unidades de resorte es fácil y conveniente.

lLas interfaces deben proporcionarse en múltiples niveles.

Spring proporciona muchas interfaces, casi todas las interfaces tienen una implementación abstracta predeterminada y cada implementación abstracta tiene algunas implementaciones específicas, por lo que Spring es sin duda excelente en escalabilidad.

El interior y el exterior de la caja deben tratarse de forma diferente.

Las partes internas de un framework pueden ser complejas, pero deben ser simples y fáciles de usar. Spring es más complicado internamente, pero oculta muy bien esta complejidad y es muy cómodo de usar. Por ejemplo, la configuración de las propiedades de un bean solo se puede realizar estableciendo el valor de la propiedad (nombre de propiedad de cadena, valor del objeto). En cuanto a cómo configurarlo, Spring oculta por completo esta complejidad.

lDocumentación completa y conjunto de pruebas

No hace falta decir que el material de los extranjeros es perfecto

Proceso básico del framework Spring Web

Ahora que Conocemos el marco Spring MVC, veamos su flujo.

El proceso general del marco Spring MVC es el siguiente:

Cuando se inicia el programa web, ContextLoaderServlet leerá la información del archivo de configuración correspondiente e inicializará el controlador DispatchServlet inyectándolo. Al recibir una solicitud HTTP, DispatchServlet permitirá que HandlerMapping maneje la solicitud. HandlerMapping puede seleccionar un controlador según la URL personalizada de la solicitud (no necesariamente la URL, que es muy flexible). DispatchServlet luego llamará al método handlerRequest del controlador seleccionado, llamando al interceptor del controlador (si está configurado) antes y después de este método. Luego devuelve la colección de vistas y modelos ModelAndView. El marco analiza la vista a través de viewResolver y devuelve un objeto de vista, y finalmente llama al método de representación de View para devolverlo al cliente.

Red de servicio Dispatcher

Este es el controlador del marco, una clase concreta que es inicializada por el objeto de contexto en tiempo de ejecución. El controlador en sí no controla el proceso, sino que es el "controlador" del controlador. Simplemente delega la responsabilidad de procesar las solicitudes al controlador correspondiente.

El controlador hereda de la clase base abstracta FrameworkServlet y su atributo webApplicationContext representa el contexto de este programa web. La implementación predeterminada de este objeto Context es leer información de configuración de un archivo XML (por supuesto que puede). también estar en otros formatos de archivo) ). WebApplicationContext es en realidad un paquete de beans. Este paquete proporciona la estructura básica de todo el marco Spring. Analizaré el contenido de este paquete más adelante. Pero ahora sólo necesito saber que WebApplicationContext representa un objeto de contexto de aplicación web.

Ahora veamos cómo funciona DispatchServlet:

DispatchServlet hereda de la clase base abstracta FrameworkServlet. Los métodos doget() y dopost() en FrameworkServlet llaman a serviceWrapper(), saltan a serviceWrapper. () para ver. Resulta que delega la implementación específica a doService (solicitud, respuesta). método. Ahora está claro que el método doService() es la función real de DispatchServlet.

En particular, el método FrameworkServlet initFrameworkServlet() es el método de inicialización del controlador. Se utiliza para inicializar objetos como HandlerMappings y también se retrasa hasta la implementación de la subclase. De hecho, es una implementación del patrón de plantilla. En términos generales, Spring implementa su inversión de control utilizando el marco en lugar del usuario.

Salte a doService() y encontrará que otra función auxiliar doDispatch(solicitud, respuesta) es realmente útil. De ninguna manera, sigue leyendo y encuentra dos líneas de código como esta.

cadena de ejecución del controlador mapped handler = null;

mapped handler = getHandler(solicitud procesada, false);

Al observar el código fuente de HandlerExecutionChain, encontramos que en realidad envuelve el controlador y su interceptor;

GetHandler() recupera el objeto handlerMapping correspondiente de handlerMapping (esta es una lista que almacena objetos Handler Mapping). Cada objeto HandlerMapping representa una asignación entre un controlador y una URL (en realidad, una asignación entre el tiempo de ejecución HandlerExecutionChain y una URL). El objeto HandlerExecutionChain es en realidad un contenedor para el controlador y sus interceptores pueden verse como una asignación entre el controlador y la URL. , este HandlerMapping se inyecta a través del archivo de configuración en tiempo de ejecución y generalmente es una subclase de SimpleUrlHandlerMapping.

Obtenga el objeto HandlerMapping, continúe mirando hacia abajo y encuentre:

if(mapped handler . get interceptors()!= null) {

for( int I = 0; i & ltmappedHandler.getInterceptors(). length; i++) {

interceptor de controlador = controlador mapeado()[I];

if (! interceptor . prehandle(solicitud procesada, respuesta, controlador asignado. gethandler()){

triggerAfterCompletion(controlador asignado, índice de interceptor, solicitud procesada, respuesta, nulo);

Retorno;

}

índice del interceptor = I;

}

}

Aquí está el interceptor llamando al controlador El principio. es esta oración:

interceptor.prehandle(solicitud procesada, respuesta, mappedHandler.getHandler(), mv

El método preHandle pasa el parámetro mappedHandler.getHandler(); interceptor de llamadas recursivas. El método .postHandle es muy general, excepto que este método se llama después del método handleRequest.

Continuar leyendo:

handler adaptor ha = gethandler adaptor(mapped handler . gethandler());

mv = ha.handle(processedRequest, respuesta, controlador mapeado. gethandler());

Se descubre que la operación real del handleRequest del controlador está delegada al método Handle del handlerAdapter y devuelve un ModelAndView. Creo que el propósito de agregar una capa aquí es desacoplar el controlador del DispatchServlet.

Eso es fácil.

Se llama al método render(), en el que ViewResoler resuelve el nombre de la vista y luego llama al método de renderizado del objeto de vista para mostrar la vista apropiada al usuario.

En este punto finaliza el proceso de controlador.

Asignación de controladores

Al utilizar HandlerMapping, los controladores pueden realizar asignaciones estándar entre URL y un controlador, e implementar UrlHandlerMapping para subclases específicas de asignación de URL.

Spring también nos permite personalizar el mapeo, como por sesión, cookie o estado del usuario. Todo lo que esto requiere es implementar la interfaz HandlerMapping. Sin embargo, el mapeo de URL ya satisface la mayoría de las necesidades.

Controladores

Los controladores son similares a las acciones de una estructura. La interfaz del controlador tiene solo un método, handleRequest(), que devuelve el objeto ModelAndView. Como dice el objetivo de diseño, cada controlador es un componente de Java, por lo que se puede configurar a voluntad en el contexto y las propiedades del componente se configurarán durante la inicialización. Spring proporciona varias implementaciones específicas para que las usemos.

Resolución de vistas

El controlador generalmente devuelve un objeto ModelAndView que contiene el nombre de la vista en lugar del objeto de la vista, desacoplando así completamente la relación entre el controlador y la vista, aquí el soporte internacional también puede ser proporcionado.

En su perfil puede:

vista de bienvenida .class = org .vista de servlet web de primavera

welcomeView.url=. /welcome.jsp

También muy buena

vista de bienvenida. class = org.vista de servlet web de primavera. view.url=/xslt/default.xslt

Perspectiva

Este también es un componente de Java, no realiza ningún procesamiento de solicitudes ni lógica de negocios. Simplemente toma los datos pasados ​​por el modelo y los muestra. El método de renderizado funciona de acuerdo con el siguiente proceso:

l Establece los datos del modelo en el rango de solicitud.

Obtuve la URL de la vista.

Reenvío a la URL correspondiente

Resumen:

El framework web de Spring es un framework excelente. Aquí hay solo un análisis aproximado del flujo de trabajo de Spring y algunas clases clave, sin entrar en las ideas detrás de él, así como sus ventajas y desventajas. Hablemos de ello la próxima vez.