Struts1 requiere que las clases de Acción hereden 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 hilo:
• Struts1 Action es un modo singleton y debe ser seguro para subprocesos, porque solo una instancia de Action 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. (De hecho, el contenedor de servlets genera muchos objetos descartables por solicitud y no causa problemas de rendimiento ni de reciclaje de LJ)
Dependencias de servlets:
• La acción Struts1 se basa en la API de Servlet porque HttpServletRequest y HttpServletResponse se pasan al método de ejecución cuando se llama a una acción.
• La acción de Struts 2 no depende del contenedor, lo que permite que la acción se pruebe 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.
Comprobabilidad:
• Un problema importante al probar las acciones de Struts 1 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.
Entrada de captura:
• Struts1 utiliza objetos ActionForm para capturar la 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 y, por lo 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.
• Struts2 puede usar JSTL, pero también admite un lenguaje de expresión más potente y flexible: "Object Graph Notation Language" (OGNL).
Vincular el valor a la página (ver):
• Struts 1 utiliza mecanismos JSP estándar para vincular objetos a páginas 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 Cadena. 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.
controlar:
• 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 procesadores de solicitudes (ciclo de vida) separados para cada módulo, 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
Este artículo proviene del blog de CSDN. Indique la fuente al reimprimir: http://blog.csdn.net/Ryan_lz/archive/2009/12/29/5101758.aspx.