Página de inicio del autor: Brújula de programación
Sobre el autor: Creador de alta calidad en el campo de Java, experto en blogs de CSDN, autor invitado de Nuggets, muchos años de experiencia en diseño de arquitectos, profesor residente en Tencent Classroom
Contenido principal: proyecto Java, diseño de graduación, plantilla de currículum, materiales de aprendizaje, banco de preguntas de entrevistas, asistencia técnica mutua
Favoritos, likes, no se pierdan, es bueno seguir al autor
Obtenga el código fuente al final del artículo
Nota: si necesita solicitar el documento original en inglés, verifíquelo al final del artículo después de tres enlaces
La arquitectura MVC impulsa la refactorización para realizar la composición de la página web del cliente
- introducir
En una aplicación web, las páginas web suelen compartir contenido como encabezados, pies de página y menús. Las plantillas se utilizan para mantener este contenido común en un solo lugar y están separadas del contenido específico de la página. Aplicaciones web basadas en plantillas (TWA usa dichas plantillas para generar dinámicamente páginas web, combinando contenido específico de página con plantillas. Por ejemplo, en la Figura 1, se generan tres páginas usando una plantilla y los detalles de cada página.
TW básicamente interactúa con el usuario, utilizando el modelo de aplicación de múltiples páginas, cuando un usuario realiza una solicitud, un navegador web descarga y muestra una nueva página. Como se muestra en la Figura 2a, una de las cosas más importantes de TWA es que el servidor combina y envía plantillas juntas y usa contenido específico de la página en cada solicitud. Por lo tanto, la plantilla se transmite de forma redundante y se procesa con una actualización de página completa en cada solicitud.
Una solución al problema de duplicados anterior es mover la composición de la página del servidor al navegador. Cada vez que un usuario hace clic en un hipervínculo o envía un formulario, el navegador web recibe la diferencia entre la página actual y la página nueva, y luego actualiza parcialmente la página actual con la diferencia, sin actualizar la página completa. Como se muestra en la Figura 2b, cada solicitud ReqI/ y Req2/ utiliza una actualización de página parcial con su diferencia asociada. Page PI es en realidad una página, pero puede tener un localizador uniforme de recursos (URL) diferente, dependiendo de su estado (es decir, el contenido que contiene). Estas aplicaciones web se conocen como aplicaciones de una sola página (SPA).
Figura 1. Aplicaciones web basadas en plantillas En las aplicaciones web Java, la acción estándar <jsp:include> se usa a menudo para llenar los marcadores de posición de la plantilla con contenido específico de la página.
Figura 2. Composición de la página web
La arquitectura Model-View-Controller (MVC) se usa comúnmente en el desarrollo de aplicaciones web. Por lo tanto, es natural considerar los tres componentes y sus interacciones como la unidad básica de análisis y modificación al reorganizar o rediseñar una aplicación de varias páginas en una aplicación de una sola página. Sin embargo, estos componentes arquitectónicos tienen problemas de transformación que no se han discutido adecuadamente en la mayoría de los trabajos anteriores.
Básicamente, una transformación requiere que se satisfagan sus requisitos previos antes de poder ejecutarse. En particular, la duplicación reducida de código/datos a veces puede dar lugar a incoherencias entre las aplicaciones de origen y de destino: el comportamiento observable de la aplicación de destino puede diferir del de la aplicación de origen. Sin embargo, la mayoría de las investigaciones previas sobre problemas transformacionales no especifican situaciones en las que no se puedan aplicar métodos transformacionales.
Por lo tanto, es necesario especificar los requisitos previos para los pasos de transformación en términos de construcción de componentes del patrón MVC. Este documento propone un método para decidir si una solicitud de página completa determinada se puede refactorizar en una solicitud de página parcial sin cambiar el comportamiento observable de la aplicación de origen desde el punto de vista de la aplicación de la arquitectura MVC. También se propone un algoritmo de reconstrucción para describir los pasos de reorganización y las premisas de recombinación. Presentamos el panorama general de la reorganización para tratar la ejecución de un algoritmo como una actividad. Además, el documento describe problemas importantes que encontramos al implementar el algoritmo de reorganización. Además, presentamos los resultados de un estudio de caso que muestran que cuando se utilizan nuestras herramientas, se reduce el esfuerzo requerido para la reorganización y se mejora el rendimiento de las aplicaciones web.
2. Pregunta y antecedentes
Los problemas de reorganización abordados en este documento pueden tener en cuenta que la reorganización de bajo nivel de la estructura de la interfaz de usuario (UI), el modelo de navegación de páginas (es decir, enlaces entre páginas web), el modelo de datos y las aplicaciones fuente funcionales no cambian. La aplicación de destino tiene el mismo aspecto que la aplicación de origen, pero mejora el tiempo de respuesta y el rendimiento por la cantidad de datos transferidos a través de la red y proporciona capacidades de comunicación asincrónica entre el servidor y el navegador. Además, el acoplamiento entre la plantilla y el contenido específico de la página reduce el contenido a través de la reorganización, por lo que el mantenimiento (por ejemplo, agregar nuevo contenido específico de la página para nuevos requisitos) se puede realizar más fácilmente. La justificación para elegir la reorganización de bajo nivel es refactorizar sin problemas la arquitectura de varias páginas de la aplicación de entrada en una arquitectura de una sola página sin confundir a los usuarios. Suponemos que la entrada TW As está utilizando la arquitectura del Modelo 2 de Java Server Pages (JSP) que adopta el patrón MVC. Esta suposición es razonable ya que la arquitectura JSP Model 2 se mencionó en las primeras especificaciones de JSP de JSP y obtuvo una amplia aceptación en la industria.
Hay muchos enfoques para reestructurar el problema o rediseñar una aplicación de varias páginas como SPA. Sin embargo, es difícil encontrar una perspectiva sobre el patrón MVC, que es un patrón arquitectónico popular para el desarrollo de aplicaciones web, que aborde este problema. Una versión anterior de este artículo consideraba explícitamente modelos, vistas, controladores y sus interacciones de modificación. Sin embargo, estudios previos tienen algunas limitaciones. La premisa de la reorganización no es la descripción. No se muestra ningún algoritmo para realizar la reorganización automáticamente, por lo que implementar este método no es fácil. Los resultados experimentales no se muestran para el proceso de recombinación.
En este artículo, mejoramos investigaciones previas y proponemos un algoritmo que considera la reorganización de las verificaciones de consistencia de entrada-salida entre aplicaciones desde la perspectiva del patrón MVC. Además, presentamos los resultados del caso de estudio en cuanto a la calidad del proceso.
Esta subsección describe sucintamente la claridad de nuestro trabajo anterior para ayudar a las personas a comprender más acerca de este documento. Una aplicación web Java consiste básicamente en objetos JSP, servlet y JavaBean que se asignan a la vista, el controlador y el modelo, respectivamente, desde la perspectiva de la arquitectura MVC. Las plantillas web se han utilizado para proporcionar a los usuarios una vista uniforme y reducir el código en las aplicaciones web. Esta plantilla crea y administra componentes compartidos como menús. Cuando un usuario realiza una solicitud de una página, la solicitud se envía a un servlet, que ejecuta su lógica empresarial. Los resultados de la ejecución se incluyen luego en la plantilla para generar la página enviada al navegador. El acceso a los objetos JavaBeans para manipular los datos comerciales se realiza mediante servlets y vistas durante el procesamiento de solicitudes. imagen. La figura 3a muestra la arquitectura dinámica para manejar las solicitudes de los usuarios.
La arquitectura tiene un problema con la descarga de plantillas y la presentación de la solicitud de actualización de página completa de cada usuario. Por lo tanto, nuestro trabajo anterior propuso un método para reorganizar TWA en una composición de página web del lado del cliente para resolver el problema. La idea principal es descargar la plantilla la primera vez que se accede a la aplicación y luego, si es posible, omitir la descarga de la plantilla en visitas posteriores. Además, las solicitudes de los usuarios se convierten de solicitudes normales del Protocolo de transferencia de hipertexto (HTTP) a solicitudes asincrónicas de JavaScript y XML (AJAX) en el navegador para permitir actualizaciones parciales. Las páginas completas se escriben en el navegador con la ayuda del código JavaScript que actualiza el árbol actual del Modelo de objetos del documento (DOM) y reemplaza las partes específicas de la página anterior con las descargadas. La Figura 3b muestra la arquitectura dinámica para manejar las solicitudes de los usuarios. Por lo tanto, la aplicación de salida es SPA.
Nuestro trabajo anterior también admite la navegación hacia atrás y la funcionalidad de marcadores para permitir el acceso a aplicaciones reorganizadas de la misma manera que las aplicaciones web clásicas. Cuando el usuario hace clic en el botón Atrás del navegador en el SPA, el navegador no volverá al estado anterior del SPA de forma predeterminada, sino que visitará la página visitada antes del SPA (consulte la Figura 4a). Para abordar el problema, nuestro trabajo anterior aplicó la API de historial del lenguaje de marcado de hipertexto 5 (HTML5), que almacena el estado actual de la pila del historial del navegador a pedido del usuario y recupera instrucciones cuando se usa el botón Atrás (consulte la figura 4b). Los SPA tienen diferentes estados, pero por defecto solo hay una URL. Por lo tanto, nuestro trabajo anterior también propuso un método para asignar una URL de solicitud única para cada estado para marcar y volver a visitar el estado.
3. Reorganice la aplicación basada en plantillas EN una aplicación de una sola página
- proceso de reorganización
En esta subsección, presentamos nuestro proceso de reestructuración general para modificar TWA en SPA (ver Figura 5). Estos pasos se describen brevemente a continuación.
Primero, el ingeniero implementa y entiende la fuente
Ver la aplicación desde el punto de vista del usuario. Luego recopila enlaces y formularios que se pueden volver a ensamblar mediante la emisión de solicitudes HTTP normales. Para cada solicitud, los ingenieros pueden extraer una arquitectura dinámica que se puede representar como un diagrama de colaboración similar al diagrama de la Figura 3a que muestra la colaboración entre los componentes web. La arquitectura se puede utilizar eficazmente para aplicaciones de pasos de verificación reorganizados. La extracción del esquema se puede lograr utilizando las técnicas de desarrollo de componentes de filtros y contenedores proporcionadas en Java Web. Los pasos de extracción no se describen en detalle debido al espacio limitado. Ahora, el ingeniero comprende la aplicación funcional y arquitectónica de la fuente y, por lo tanto, ejecuta un algoritmo de refactorización para reestructurar la aplicación de entrada en un SPA. Verifique que la aplicación de salida finalice después de la reorganización. Las conversiones manuales se pueden realizar cuando se encuentran problemas, incluidas conversiones perdidas e incorrectas.
Tenga en cuenta que este artículo se centra en esta transformación arquitectónica y sus herramientas de apoyo. Por lo tanto, hemos desarrollado un complemento de Eclipse para admitir el paso "ejecutar el algoritmo de reorganización", que se describe en detalle en la siguiente sección.
Figura 3. Transformación arquitectónica de la formación web del cliente
Figura 4. El problema de la navegación hacia atrás y la solución de Oh et al.
Figura 5. Proceso de reorganización general
- algoritmo de reconstrucción
Primero, el TWA se analiza para recopilar una lista de solicitudes de página completa, luego cada solicitud se analiza si es posible, modificada para solicitudes de página parcial mediante transformRequestO (consulte las líneas 1-15). Si la solicitud transformada lleva el SPA resultante a un estado inconsistente, es decir, la solicitud de estado original no se transforma (ver líneas 5-7). Por lo tanto, la aplicación de salida puede ser una aplicación de varias páginas, donde cada página se ejecuta como una aplicación de una sola página. Este estado inconsistente puede surgir en tres casos desde una arquitectura de perspectiva MVC.
El primer caso es cuando la solicitud transformada genera una vista que no existe en TWA (ver línea 20). Por ejemplo, supongamos que tenemos una solicitud de página completa que cambia la plantilla actual y el contenido específico de la página. Si r se transforma para descargar nuevas solicitudes de página parciales para contenido específico de página, la solicitud transformada producirá una vista incoherente.
La plantilla no es una página estática, sino una página dinámica. Diferentes objetos de plantilla crean instancias de clases a partir de plantillas, según el estado del sistema/usuario. Por ejemplo, en la figura, el objeto de plantilla se reemplaza después de que el usuario inicia sesión porque su menú es diferente. Cuando una solicitud de usuario requiere una nueva instancia de plantilla, el SPA también debe descargar la nueva instancia. Uno de los diseños posibles es descargar la diferencia entre el objeto de plantilla antiguo y el objeto de plantilla nuevo. Sin embargo, estas diferencias pueden estar dispersas en los objetos de la plantilla mundial, por lo que no es fácil de implementar. Por lo tanto, tomamos la decisión de no convertir la solicitud de página completa original.
El segundo caso es cuando una solicitud de transformación de la imagen original da como resultado una situación inapropiada: 1) se introduce un controlador no válido en el SPA, o 2) se realiza una solicitud a un controlador diferente al que esperábamos en TWA (ver líneas 21- 23 ).
En primer lugar, los navegadores web ejecutan código del lado del cliente en HTML, hojas de estilo en cascada (CSS) y JavaScript. Entre ellos, el código JavaScript juega el papel del controlador del cliente. Una de las cosas importantes sobre el código del lado del cliente es que cuando se reemplaza el contenido específico de la página, su efecto secundario es ejecutar el código JavaScript del contenido específico de la página anterior, a diferencia del código HTML y CSS. Por otro lado, una solicitud de página completa descargará todo el código de cliente de la página anterior. Por lo tanto, se requiere un análisis para determinar si el código JavaScript desactualizado hace que los SPA se comporten de manera diferente a los TWA. Una TWA para un escenario específico que cambia el comportamiento observable es la siguiente: por ejemplo, suponga una TWA específica de una página en la que parte de una página tiene código JavaScript que descarga una página de imagen cada vez que el usuario se desplaza hacia abajo (por ejemplo, a través de window. manejo de eventos onScrollO en un programa de solicitud AJAX) para reducir el tiempo de carga de la página. Si el usuario se mueve a una nueva página física, dicho código de manejo de eventos se elimina automáticamente debido a la descarga de la página. Sin embargo, en un SPA reestructurado, el código que se elimina no ocurre automáticamente, ya que ingresar un nuevo estado no provoca una actualización completa de la página. Esto significa que existe un controlador no válido en el SPA (línea 21).
En segundo lugar, el SPA debe conservar el modelo de navegación de la página (incluida la navegación hacia atrás/adelante y la actualización) importado en TWA. Por ejemplo, supongamos que la página PI de TWA se reestructura en la página p de SPA, de modo que Ps es igual a PI y ambas páginas se actualizan, y la nueva página también debe ser la misma. Para lograr esto, cada estado de SPA tiene una única URL, por ejemplo, todas las páginas de TWA. La URL de este estado debe contener información utilizada para identificar el estado (por ejemplo, solicitar la URL para obtener el contenido específico de la página). Por lo tanto, cuando se actualiza una página, la página -El contenido específico se puede obtener junto con la plantilla (consulte la Figura 8). Hay una cosa importante a tener en cuenta al refactorizar una solicitud de página completa en una solicitud de página parcial usando AJAX: cuando la solicitud inicial se redirige (a través de una redirección desde el servidor a la solicitud HTTP por parte del navegador web) a Otro componente c, la URL redirigida (es decir, la URL solicitada de c), no puede pasar a través de SPA de forma predeterminada. Por otro lado, la URL redirigida se muestra en la barra de direcciones de un navegador web con TWA. Por lo tanto, cuando intentamos actualizar la página del SPA, que incluye una solicitud de redirección HTTP como contenido específico de la página, el SPA se comporta de manera diferente a cuando ingresó el TWA. Esto significa que el SPA envió la solicitud al controlador inapropiado (líneas 22-23).
El tercer caso es donde se puede generar una solicitud de transformación para un modelo que no existe en TWA (ver línea 24). Por ejemplo, la transformación de la solicitud original para actualizar continuamente el estado del servidor puede permitir generar SPA con datos no válidos. Una situación más específica es la siguiente: Supongamos que en TWA tenemos una página que no puede enviar un formulario de pago con los mismos datos más de una vez. Sin embargo, si su forma transformada permite que los mismos datos se envíen dos veces, la transformación incurre de manera desventajosa en pagos dobles, que es un ejemplo del problema de la doble presentación.