La diferencia entre struts1 y struts2
1. Clase de acción La acción de Struts1 necesita heredar una clase base abstracta. Un problema común es que Struts1 está orientado a la programación de clases abstractas en lugar de la programación de interfaces.
La acción de Struts2 puede implementar una interfaz de Acción y también puede implementar algunas otras interfaces al mismo tiempo para agregar algunas adicionales, comúnmente servicios utilizados. Struts2 proporciona una clase base ActionSupport que implementa algunas interfaces de uso común. Aunque la interfaz Acción no es necesaria. Cualquier objeto POJO con un método de ejecución se puede utilizar como objeto de acción en Struts2.
2. Modelo de subprocesos
La acción de Struts1 es un singleton y debe ser segura para subprocesos, porque esta clase tendrá solo una referencia para manejar todas las solicitudes de la acción. La estrategia singleton impone restricciones sobre lo que se puede hacer con las acciones de Struts 1 y requiere especial cuidado para su desarrollo. Las acciones de Struts1 deben ser seguras para subprocesos y estar sincronizadas.
El objeto Acción de Struts2 es para cada solicitud, por lo que, naturalmente, no hay problemas de seguridad de subprocesos. (En realidad,)
3. Dependencias de servlet
La acción de Struts1 depende de la API de servlet, porque cuando se llama a la acción, los objetos HttpServletRequest y HttpServletResponse se procesan a través del método de ejecución.
La conexión entre Struts2 Action y el contenedor no es estrecha. Normalmente, el contexto del servlet se representa como un mapa simple, lo que permite probar las acciones de forma aislada. Por supuesto, si es necesario, Struts2 Action también puede completar algunas funciones accediendo a la solicitud y respuesta inicial. Sin embargo, otros elementos arquitectónicos han dado como resultado la reducción o eliminación de la necesidad de acceso directo a la solicitud y la respuesta.
4. Facilidad de prueba
Un gran obstáculo al probar la acción Struts1 es que el método de ejecución está expuesto directamente a la API del servlet.
La acción Struts2 se puede probar fácilmente estableciendo propiedades y llamando a métodos. Por supuesto, el soporte de inyección de dependencia también facilita las pruebas.
5. Procesamiento de entrada
Struts1 utiliza un objeto ActionForm para obtener la entrada del usuario. Al igual que la acción, todos los ActionForms deben heredar de una clase base. Debido a que otros javaBeans no se pueden usar como ActionForms, los desarrolladores generalmente tienen que escribir algunas clases redundantes para obtener la entrada del usuario. DynaBean se puede utilizar como alternativa para generar clases ActionForm, pero los desarrolladores deben reescribir los javaBeans existentes. Struts2 utiliza atributos de acción como atributos de entrada, eliminando la necesidad de objetos de entrada. La propiedad de entrada puede ser un objeto con sus propias propiedades. Los atributos de acción interactúan con las páginas web a través de etiquetas. Struts2 también admite el modelo ActionForm, que es el objeto Formulario de POJO y la Acción de POJO. La mayoría de los tipos de objetos, incluidos los objetos de lógica empresarial y los objetos de dominio, se pueden utilizar como objetos de entrada/salida. Las funciones basadas en esquemas simplifican la relación entre etiquetas y objetos de entrada POJO.
6. Lenguaje de expresión
Struts1 se combina con JSTL, por lo que puede usar EL de JSTL.
Struts2 también admite JSTL, pero este marco también admite el lenguaje de expresión más potente OGNL
7 Capa de presentación y enlace de tipo-valor
Uso de Struts1 Mecanismos JSP estándar. vincula objetos al contexto de la página para acceder.
Struts2 utiliza la tecnología "ValueStack", por lo que las etiquetas pueden obtener valores sin combinar la vista con el objeto representado. La estrategia ValueStack permite completar la vista a través de una serie de tipos que pueden tener la misma propiedad. nombre pero diferentes tipos de propiedades Reutilización,
8. Conversión de tipos
El ActionForm de Struts1 suele ser de tipo String. Struts1 implementa la conversión de tipos a través de Commons-Beanutils.
Struts2 utiliza OGNL para implementar la conversión de tipos. El marco incluye convertidores para tipos básicos y públicos.
9. Verificación
Struts1 admite la verificación manual a través del método de validación en ActionForm. La verificación también se puede realizar ampliando el marco de verificación general. Puede haber diferentes validaciones para una misma clase, pero no pueden estar relacionadas con la validación de subobjetos.
Struts2 también admite la verificación manual a través del método de validación y la verificación a través del marco de verificación Xwork. El marco de validación de Xwork admite el encadenamiento de validación a subpropiedades que utilizan la validación definida para el tipo de propiedad y el contexto de validación.
10. Control de ejecución de acciones
Struts1 admite la asignación de procesamiento de solicitudes (ciclo de vida) a cada módulo, pero todas las acciones de un 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 la pila de interceptores. Por lo general, las pilas correspondientes se crean y utilizan para diferentes acciones según sea necesario.