La diferencia entre struts2 y struts1
La diferencia y comparación entre Struts1 y Struts2:
Clase de acción: Struts1 requiere que la clase Acción herede una clase base abstracta. Un problema común con Struts1 es el uso de programación de clases abstractas en lugar de interfaces, mientras que Action de Struts2 es una interfaz. La clase Action de Struts 2 puede implementar una interfaz Action u otras interfaces, lo que hace 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 subprocesos: la acción Struts1 es un modo singleton y debe ser seguro para subprocesos, porque solo una instancia de Acción maneja todas las solicitudes. La estrategia singleton limita lo que Struts1 Action puede hacer y se debe tener especial cuidado durante el desarrollo. Los recursos de acción deben ser seguros para subprocesos o estar sincronizados. El objeto Acción 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 del servlet: la acción Struts1 depende de la API del servlet, porque cuando se llama a una acción Cuando se llama a HttpServletRequest y HttpServletResponse se pasan al método de ejecución. La acción de Struts 2 no depende del contenedor, lo que permite probar la acción 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.
Testabilidad: 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 páginas 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 y por tanto 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.
Struts 2 puede usar JSTL, pero también admite un lenguaje de expresión más potente y flexible: "Object Graph Notation Language" (OGNL).
Enlace de valores a páginas (vistas): Struts 1 usa JSP estándar. El mecanismo vincula el objeto 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 usa OGNL para la conversión de tipos. Proporciona convertidores para objetos básicos y de uso común.
Validació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 validación y validación de contenido definidas para tipos de clases de atributos para admitir subatributos de validación en cadena
Control de ejecución de acciones: Struts1 admite procesadores de solicitudes separados (ciclo de vida) para cada módulo), pero todas las acciones en el módulo debe 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.
1. Introducción La primera versión de Struts se lanzó en mayo de 2001. Su idea original era separar claramente la vista y la lógica empresarial/aplicación de las aplicaciones web mediante la combinación de JSP y Servlets. Antes de Struts, el enfoque más común era agregar lógica comercial y de aplicaciones a JSP, o generar vistas a través de println() en Servlet.
Desde el lanzamiento de la primera versión, Struts se ha convertido en un estándar de aplicaciones web reconocido en la industria. Su popularidad también ha generado mejoras y cambios, por lo que no solo debe mantenerse al día con las necesidades cambiantes de los marcos de aplicaciones web, sino también integrarse con las características cada vez más competitivas de muchos marcos. Al final, se produjeron varias soluciones Struts de próxima generación. Dos de las soluciones más destacadas son Shale y Struts Ti.
Shale es un marco basado en componentes y recientemente se ha convertido en un proyecto de nivel superior de Apache. Struts Ti continúa mejorando los modos del controlador frontal (Front Controller) y MVC (modelo-vista-controlador) basándose en la experiencia exitosa de Struts. El proyecto WebWork se lanzó en marzo de 2002. Realizó mejoras revolucionarias en el marco de Struts e introdujo muchas ideas, conceptos y funciones nuevas, pero no era compatible con el código de Struts original. WebWork es un marco maduro que ha experimentado varias mejoras y lanzamientos importantes. En diciembre de 2005, WebWork y Struts Ti anunciaron su fusión. Al mismo tiempo, Struts Ti pasó a llamarse Struts Action Framework 2.0, convirtiéndose en el verdadero sucesor de Struts. Una última cosa a tener en cuenta es que esto no significa que el desarrollo de los proyectos Struts o WebWork se haya detenido. Dado que el interés en ambos proyectos sigue siendo alto y hay muchos desarrolladores todavía dispuestos a utilizarlos, ambos proyectos continúan desarrollándose con correcciones de errores, mejoras de funciones y nuevas funciones agregadas.
2. La diferencia entre acciones Para aquellos que tienen una gran experiencia en Struts1. Sin embargo, los modelos de acción de Struts1.x y Struts2 son muy diferentes. La diferencia más obvia entre Struts2 y Struts1.x es que Struts2 es una arquitectura pull-MVC.
¿Qué significa esto? Desde la perspectiva del desarrollador, significa que los datos que deben mostrarse al usuario se pueden obtener directamente de la Acción, a diferencia de Struts1. Struts1.x debe heredar org.apache.struts.action.Action o su subclase, y los datos del formulario se encapsulan en FormBean.
Struts 2 no necesita heredar ningún tipo ni implementar ninguna interfaz. Los datos del formulario están contenidos en Action y se obtienen a través de Getter y Setter (como el siguiente ejemplo de código de ActionForStruts2). Aunque en teoría Struts2 Action no necesita implementar ninguna interfaz ni heredar ninguna clase, en el proceso de programación real, para implementar Action de manera más conveniente, en la mayoría de los casos se heredará la clase com.opensymphony.xwork2.ActionSupport y se anulará la Método de ejecución de cadena () en esta clase.
En primer lugar, como se puede ver en ActionForStruts2, el objeto devuelto no es ActionForward, sino String. Si no le gusta que aparezcan cadenas en su código, existe una Acción de interfaz auxiliar que proporciona resultados comunes como constantes, como "éxito", "ninguno", "error", "entrada" e "iniciar sesión".
Además, según la convención, solo el método "ejecutar" puede llamar a Action en Struts1.x, pero no es necesario en Struts2. Cualquier método declarado como String público nombre_método() puede configurarse para llamar. Acción. .
Finalmente, la mayor diferencia revolucionaria con Struts1.x es que el método llamado por Struts2 durante el procesamiento de la Acción (método "ejecutar") no toma parámetros.
¿Cómo conseguir el objeto requerido? La respuesta es utilizar IoC (Inversión de Control), también llamado modo "Inyección de Dependencia". El marco Spring hizo popular este modelo, pero el predecesor de Struts2 (WebWork) también aplicó este modelo al mismo tiempo.
3. IoCIoC (Inversión de Control, en lo sucesivo traducido como Inversión de Control) se está familiarizando cada vez más con la promoción de contenedores livianos (Lightweight Contianer) en la comunidad Java. Aquí no es necesario desperdiciar más palabras para explicar "qué es la inversión de control" y "por qué es necesaria la inversión de control".
Como todos sabemos, Struts2 está desarrollado en base a Webwork 2. La versión de Webwork anterior a Webwork 2.2 tenía su propia implementación de inversión de control. Webwork 2.2 decidió abandonar el desarrollo de la función de inversión de control e implementarla con Spring en el contexto del rápido desarrollo del marco Spring.
Vale la pena mencionar que Spring es de hecho un marco que vale la pena aprender, porque cada vez más componentes de código abierto (como iBATIS, etc.) están abandonando el desarrollo de funciones que se superponen con Spring. Por lo tanto, Struts2 recomienda implementar la inversión de control a través de Spring.
Para comprender mejor el control de inversión, veamos un ejemplo de cómo usar IoC para acceder al objeto HttpServerRequest de solicitud actual durante el procesamiento de la Acción. En el ejemplo, el mecanismo de inyección de dependencia utilizado es la inyección de interfaz. Como sugiere su nombre, la inyección de interfaz requiere una interfaz que ya haya sido implementada.
Esta interfaz contiene configuradores de las propiedades correspondientes para proporcionar valores para la Acción.
La interfaz ServletRequestAware se utiliza en el ejemplo, de la siguiente manera:
interfaz pública ServletRequestAware { public void setServletRequest(solicitud HttpServletRequest);}
Al heredar esta interfaz , la acción simple original parece un poco complicada, pero ahora puede obtener el objeto HttpServerRequest para su uso.
la clase pública IoCForStruts2 implementa ServletRequestAware {
solicitud HttpServletRequest privada;
setServletRequest público vacío (solicitud HttpServletRequest) {
this.request = request; }
public String ejecutar() throws Exception {
// Puedes comenzar a trabajar con el objeto de solicitud
return Action.SUCCESS }
}
Parece que estas propiedades ahora están en el nivel de clase y no son seguras para subprocesos, lo que causa problemas.
De hecho, no hay ningún problema en Struts2, porque cada solicitud generará una nueva instancia de objeto Acción. No comparte un objeto con otras solicitudes, por lo que no es necesario considerar la seguridad de los subprocesos.
Interceptor (en adelante traducido como interceptor), en AOP (Programación Orientada a Aspectos), se utiliza para interceptar antes de que se acceda a un método o campo y luego agregar ciertas operaciones antes o después.
La interceptación es una estrategia de implementación de AOP. La explicación en la documentación china de Webwork es que un interceptor es un objeto que intercepta dinámicamente las llamadas a la acción. Proporciona un mecanismo que permite a los desarrolladores definir el código que se ejecutará antes y después de ejecutar una acción, y evitar la ejecución de una acción antes de que se ejecute. También proporciona una forma de extraer partes reutilizables de la acción. El marco estándar de Struts 1.x no proporciona ningún tipo de interceptor. Aunque un proyecto adicional llamado SAIF implementa dicha función, su alcance de aplicación aún es muy limitado.
El interceptor es una herramienta poderosa de Struts2 y muchas funciones se basan en él, como internacionalización, convertidores, verificación, etc. Hablando de interceptores, hay otra palabra popular: cadena de interceptores (Cadena de interceptores, llamada pila de interceptores Interceptor Stack en Struts2).
La cadena de interceptores consiste en conectar interceptores en una cadena en un orden determinado. Cuando se accede a un método o campo interceptado, se llamará a los interceptores de la cadena de interceptores en el orden en que se definieron previamente.
La implementación del interceptor de Struts 2 es relativamente simple.
Cuando la solicitud llega al ServletDispatcher de Struts 2, Struts 2 buscará el archivo de configuración, creará una instancia del objeto interceptor relativo de acuerdo con su configuración, luego lo encadenará en una lista y finalmente llamará a los interceptores en la lista uno por uno. uno. Struts 2 proporciona una rica variedad de implementaciones de interceptores completamente funcionales.
Los lectores pueden ir al struts-default.xml del paquete struts2-all-2.0.6.jar o struts2-core-2.0.6.jar para ver la configuración del interceptor predeterminado y la cadena de interceptores. . Como "marco", la escalabilidad es indispensable porque no existe un enfoque único que sirva para todos.
Aunque Struts 2 nos proporciona un conjunto tan rico de implementaciones de interceptores, eso no significa que perdamos la capacidad de crear interceptores personalizados. Al contrario, es bastante fácil personalizar interceptores en Struts 2. Una cosa.
Presenté brevemente el origen de Struts2 y comparé las diferencias entre Struts2 y Struts1, y entendí las diferencias en Acción entre Struts1.
Al mismo tiempo, debe comprender: Struts2 es una actualización de WebWork, no una actualización de Struts 1.x. Aunque Struts 2 proporciona compatibilidad con Struts1.x, ya no es una actualización de Struts1.x. Para los desarrolladores que ya tienen experiencia en el desarrollo de Struts1.x, la experiencia de desarrollo de Struts1 será una buena referencia para el desarrollo.