¿Cuál es el principio de funcionamiento central de Struts2?
El marco de Struts 2 consta de tres partes: el controlador central FilterDispatcher, el controlador empresarial y los componentes de lógica empresarial implementados por el usuario. Entre estas tres partes, el marco Struts 2 proporciona el controlador central FilterDispatcher, y los usuarios deben implementar controladores comerciales y componentes de lógica empresarial.
2. Controlador central: programador de filtros.
FilterDispatcher es el controlador central del marco Struts 2. Como filtro, el controlador se ejecuta en la aplicación web y es responsable de interceptar todas las solicitudes de los usuarios. Cuando llega una solicitud de usuario, el filtro filtrará la solicitud del usuario. Si la solicitud del usuario finaliza con una acción, la solicitud se transferirá al marco Struts 2 para su procesamiento.
Después de que el marco Struts 2 obtenga *. Solicitud de acción, decidirá qué componente de lógica de negocios llamar en función de la parte * anterior. Solicitud de acción. Por ejemplo, para una solicitud login.action, Struts 2 llama a una acción denominada login para manejar la solicitud.
Las acciones en las aplicaciones Struts 2 se definen en el archivo struts.xml. Cuando se define una operación en este archivo, se definen el atributo de nombre y el atributo de clase de la operación. El atributo de nombre determina qué solicitud de usuario maneja la operación y el atributo de clase determina la clase de implementación de la operación.
La instancia de acción utilizada por Struts 2 para manejar las solicitudes de los usuarios no es el controlador de negocios implementado por el usuario, sino el proxy de acción; debido a que el controlador de negocios implementado por el usuario no está acoplado con la API de Servlet, obviamente es incapaz de atender las solicitudes de los usuarios. El marco Struts 2 proporciona una serie de interceptores que son responsables de analizar los parámetros de la solicitud en HttpServletRequest, pasarlos a la acción y volver a llamar al método de ejecución de la acción para manejar la solicitud del usuario.
Obviamente, el proceso anterior es un método de procesamiento típico de AOP (programación orientada a aspectos). La figura 3.19 muestra este modelo de procesamiento.
Figura 3.19 Acciones de Interceptor y Struts 2
Como se puede ver en la Figura 3.19, la clase de acción implementada por el usuario es solo el objetivo del proxy de acción de Struts 2. Los controladores de servicios (acciones) implementados por el usuario incluyen el procesamiento de solicitudes de los usuarios. Los datos de la solicitud del usuario están contenidos en el objeto HttpServletRequest y la clase Acción del usuario no necesita acceder al objeto HttpServletRequest. El interceptor es responsable de analizar los datos de la solicitud en HttpServletRequest y pasarlos a la instancia de acción del componente de lógica empresarial.
3. Controlador de servicio
Como se puede ver en la Figura 3.19, el componente del controlador de negocio es un ejemplo del usuario que implementa la clase Acción. Las clases de acción normalmente contienen un método de ejecución, que devuelve una cadena; esta cadena es el nombre de una vista lógica. Cuando el controlador de negocios ha procesado la solicitud del usuario, el método de ejecución devuelve diferentes cadenas; cada cadena corresponde a un nombre de vista.
En mi opinión, la pregunta debería ser si tiene cierta comprensión del diseño de la arquitectura del sistema y si puede expresar claramente los puntos de comunicación en el diseño de software con su propia comprensión.