¿Qué son los struts? ¿Hablemos de su mecanismo de funcionamiento y cuáles son sus ventajas?

1. ¿Cómo maneja Struts2 una solicitud de usuario?

1. Primero, el usuario envía una solicitud y la intercepta a través del interceptor filterDispatcher.

2. filterDispatcher le pedirá a ActionMapper que determine si esta solicitud necesita llamar a una acción.

3. Este ActionMapper encapsula la información solicitada. Si ActionMapper decide que es necesario llamar a una acción, FilterDispatcher creará un objeto proxy para la acción en función de la información (el nombre de la acción, el nombre del método que se llama). De hecho, el llamado a la acción se implementa a través de este objeto proxy.

4. Entregue la solicitud al agente. Si la solicitud enviada por el usuario no especifica un método, Struts2 utilizará de forma predeterminada el método de ejecución. Este agente crea una instancia del planificador.

Este programador define un método de invocación, que implementa la interacción del interceptor y la ejecución del método de ejecución en la Acción.

5. El interceptor se llama en forma de pila de valores.

Struts2 tiene 18 interceptores por defecto. El primer interceptor es un interceptor de excepciones. En este caso, si mi primer interceptor detecta la excepción, no necesitaré detectar las excepciones que se produzcan en otros interceptores en el futuro.

6. Después de ejecutar la Acción, el programador será responsable de encontrar el resultado de retorno correspondiente según la configuración en struts.xml.

7. Luego, el programador devuelve todos los interceptores y devuelve el conjunto de resultados al cliente a través de la respuesta.

En segundo lugar, la diferencia entre Struts2 y Struts1

Clase de acción:

Struts1 requiere que la clase Acción herede una clase base abstracta. Un problema común con Struts1 es la programación con clases abstractas en lugar de interfaces.

La clase Action de Struts 2 puede implementar una interfaz Action u otras interfaces, haciendo posibles servicios opcionales y personalizados. Struts2 proporciona una clase base ActionSupport para implementar interfaces de uso común. La interfaz Action no es necesaria. Cualquier objeto POJO con el identificador de ejecución se puede utilizar como objeto Action de Struts2.

Modo de subproceso:

La acción Struts1 es un modo singleton y debe ser segura para subprocesos, porque solo una instancia de Acción maneja todas las solicitudes. La estrategia singleton limita lo que Struts1 Action puede hacer y requiere especial cuidado durante su desarrollo. Los recursos de acción deben ser seguros para subprocesos o estar sincronizados.

El objeto Acción de Struts2 genera una instancia para cada solicitud, por lo que no hay problemas de seguridad de subprocesos. (En realidad, el contenedor de servlets genera muchos objetos descartables para cada solicitud y no causa problemas de rendimiento ni de recolección de basura)

Dependencias de servlet:

La acción de Struts1 depende de la API de Servlet, porque HttpServletRequest y HttpServletResponse se pasan al método de ejecución cuando se llama a una acción.

Struts 2 Action no depende del contenedor, lo que permite probar Action independientemente del contenedor.

Struts2 Action aún puede acceder a la solicitud y respuesta originales si es necesario. Sin embargo, otros elementos reducen o eliminan la necesidad de acceder directamente a HttpServetRequest y HttpServletResponse.

Capacidad de prueba:

Un problema importante al probar las acciones de Struts1 es que el método de ejecución expone la API del servlet (lo que hace que las pruebas dependan del contenedor). Una extensión de terceros, Struts TestCase, proporciona un conjunto de objetos simulados de Struts1 (para pruebas).

La acción de Struts 2 se puede probar inicializando, configurando propiedades y llamando a métodos. El soporte de "inyección de dependencia" también facilita las pruebas.

Captura de entrada:

Struts1 utiliza objetos ActionForm para capturar entrada. Todos los ActionForms deben heredar una clase base. Debido a que otros JavaBeans no se pueden utilizar como ActionForms, los desarrolladores suelen crear clases redundantes para capturar entradas. Los Beans dinámicos (DynaBeans) se pueden utilizar como una alternativa a la creación de ActionForms tradicionales. Sin embargo, los desarrolladores pueden estar redescribiendo (creando) JavaBeans existentes (lo que aún resulta en JavaBeans redundantes).

Struts 2 utiliza propiedades de acción directamente como propiedades de entrada, eliminando la necesidad de un segundo objeto de entrada. Las propiedades de entrada pueden ser tipos de objetos enriquecidos con sus propias (sub)propiedades. Se puede acceder a las propiedades de la acción a través de taglibs en la página web. Struts2 también admite el modo ActionForm. Se pueden utilizar tipos de objetos enriquecidos, incluidos objetos comerciales, como objetos de entrada/salida. Esta característica ModelDriven simplifica la referencia de taglib a objetos de entrada POJO.

Lenguaje de expresión:

Struts1 integra JSTL, por lo que utiliza JSTL EL. Este EL tiene un recorrido básico de gráficos de objetos, pero el soporte para colecciones y propiedades indexadas es débil.

Struts2 puede usar JSTL, pero también admite un lenguaje de expresión más potente y flexible: "Object Graph Notation Language" (OGNL).

Vincula valores a la página (ver). :

Struts 1 utiliza el mecanismo JSP estándar para vincular objetos a la página para acceder.

Struts 2 utiliza la tecnología "ValueStack" para permitir que taglib acceda a los valores sin vincular su página (vista) al objeto. La estrategia ValueStack permite la reutilización de páginas (vistas) a través de una serie de propiedades con el mismo nombre pero de diferente tipo.

Conversión de tipo:

Las propiedades de Struts 1 ActionForm suelen ser de tipo String. Struts1 usa Commons-Beanutils para la conversión de tipos. Un convertidor por clase, no configurable por instancia.

Struts2 utiliza OGNL para la conversión de tipos. Proporciona convertidores para objetos básicos y de uso común.

Verificación:

Struts 1 admite la verificación manual en el método de validación de ActionForm, o la verificación a través de la extensión de Commons Validator. La misma clase puede tener diferentes contenidos de verificación, pero los subobjetos no se pueden verificar.

Struts2 admite la verificación a través del método de validación y el marco de verificación XWork.

El marco de validación de XWork utiliza la validación y la validación de contenido definidas para el tipo de clase de atributo para admitir la subpropiedad de validación de cadena

Control de ejecución de acciones:

Struts1 admite cada módulo con procesadores de solicitudes separados (ciclo de vida), pero todas las acciones del módulo deben compartir el mismo ciclo de vida.

Struts2 admite la creación de diferentes ciclos de vida para cada acción a través de Interceptor Stacks. Las pilas se pueden utilizar con diferentes acciones según sea necesario.

En tercer lugar, el marco Struts2 carga las constantes de Struts2 en el siguiente orden de búsqueda:

struts-default.xml se guarda en struts2-core-version.jar

struts-plugin .xml se guarda en struts2-Xxx-version.jar

struts.xml El archivo de configuración predeterminado de Struts2 para aplicaciones web

struts.properties El archivo de configuración predeterminado de Struts2 para web aplicaciones

Archivo de configuración de aplicación web web.xml

Si la misma constante Struts2 está configurada en varios archivos, el valor constante configurado en el último archivo sobrescribirá la constante configurada en el archivo anterior. .

Cuarto. Cuando struts2 encuentra un error de conversión de tipo, struts2 genera automáticamente un mensaje de error y lo coloca automáticamente en addFieldError.

En quinto lugar, es posible que algunos lectores pregunten. Preguntas, ¿por qué los buenos objetos Servlet se encapsulan aquí en objetos Map? Creo que puede haber dos razones:

1. Proteger completamente el contenedor de Servlet de la acción Struts2, eliminando la necesidad de utilizar la API de Servlet subyacente para la programación. Lo que enfrentarás siempre será un objeto Java tras otro.

2. Facilite varias tecnologías de visualización, como JSP, Freemarker, Velocity, etc., para leer el entorno contextual en ValueStack, especialmente los datos en el objeto Servlet. Imagínense, si no convertimos objetos Servlet como HttpServletRequest y HttpSession en Maps aquí, nos resultará difícil leer los valores en estos objetos Servlet a través de expresiones OGNL.

6. Verificar validar. Primero ejecute el método validarMethod y luego ejecutar el método de validación ejecutar el método validarExecute()

7. Verificación de campo (de uso común) y verificación sin campo

p>

Verificación del lado del cliente: 1. El tema del formulario no debe establecerse en simple

2. Establezca el atributo de validación del formulario en verdadero

Es mejor no usar struts2 Los métodos de verificación del cliente que proporcionamos

Ocho, fieldError

1, el objeto de información realmente almacenado en el error de nivel de campo es LinkdedHashMp

2 , LinkedHashMap La clave es de tipo String y el valor es de tipo ArrayList

3. Los mensajes de error a nivel de acción en realidad se colocan en ArrayList

9. >

Podemos imaginar struts2 como un contenedor, configurado con muchos interceptores y luego llamado capa por capa

lt; interceptor-refgt;/interceptor-refgt; p>

lt; interceptor-ref name=”defaultStack” gt; /interceptor-refgt;

El interceptor configurado primero se ejecutará primero y el interceptor configurado primero saldrá al final ( entrar y salir)

p>

lt; includegt; tiene una prioridad más alta que lt; maravillosa pila de interceptores en Struts 2.0, por lo que muchas personas se preguntan por qué no está configurada como la pila de interceptores predeterminada. paramsPrepareParamsStack resuelve principalmente el problema de la cooperación entre ModelDriven y Preparable. Literalmente, el orden de llamada del interceptor de esta pila es: primero params, luego prepare, luego modelDriven y finalmente params. El diseño de Struts 2.0 requiere que se llame a modelDriven antes que a params. En los negocios, prepare es responsable de preparar el modelo, y preparar el modelo requiere parámetros para ejecutar el interceptor de parámetros antes de prepararlo. paramsPrepareParamsStack.

El proceso es el siguiente:

1. El interceptor de parámetros primero asigna valores a los parámetros relevantes en la acción, como id

2. El interceptor de preparación ejecuta el método de preparación y el método de preparación se basará en parámetros, como id, para llamar a la lógica de negocios y configurar el objeto modelo

3. El interceptor modelDriven empuja el objeto modelo a la pila de valores. aquí se crea en prepare

4. params El interceptor luego asigna los parámetros al objeto modelo

5. La lógica empresarial de la acción se ejecuta en función de esta pila

Once, la parte de acoplamiento entre sturts2 y Servlet

(1) ActonContext.getContext() (Convierte solicitudes, sesiones, etc. en mapas, conveniente para pruebas, pero no hay una interfaz httpresponse)

(2) La interfaz ServletResponseAware y ServletRequestAware implementa el método setServletResponse() y el método servletResquest() respectivamente.

El marco Struts2 configura automáticamente el objeto de solicitud relacionado con el contenedor en la aplicación. IOC típico

(3) ServletActionContext se puede obtener llamando directamente a la solicitud del método estático y otros objetos

Se recomienda utilizar el primer método, porque aunque está acoplado con el servlet , servletAPI realmente no aparece y toda la acción sigue siendo muy limpia. Si desea utilizar httpresponse, puede utilizar el tercer método.