La diferencia entre struts1 y struts2
La acción de Struts2 puede implementar la interfaz Action, pero también puede implementar otras interfaces al mismo tiempo para agregar algunas adicionales, comúnmente usado Servir. La clase base ActionSupport proporcionada por Struts2 implementa muchas 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 solo hay una referencia de acción en la clase para manejar todas las solicitudes. La estrategia singleton limita la funcionalidad de las operaciones de Struts1 y, por lo tanto, requiere especial cuidado durante el desarrollo. Las operaciones de Struts1 deben ser seguras para subprocesos y estar sincronizadas.
Los objetos de acción de Struts 2 son por solicitud, por lo que, naturalmente, no son seguros para subprocesos. (De hecho,)
3. Dependencia del servlet
La acción de Struts1 depende de la API del servlet, porque cuando se llama a la acción, los objetos HttpServletRequest y HttpServletResponse se procesarán a través del método de ejecución. .
Las acciones de Struts2 no están estrechamente conectadas al contenedor. Normalmente, el contexto del servlet se representa como un mapa simple, lo que permite probar las acciones individualmente. Por supuesto, si es necesario, Struts2 Actions también puede realizar algunas funciones accediendo a la solicitud y respuesta inicial. Sin embargo, otros elementos arquitectónicos pueden reducir o eliminar la necesidad de acceso directo a solicitudes y respuestas.
4. Fácil de probar
Uno de los obstáculos al probar las operaciones de 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 configurando propiedades para llamar a métodos. Por supuesto, el soporte de inyección de dependencia también facilita las pruebas.
5. Procesamiento de entrada
Struts1 utiliza objetos ActionForm para obtener la entrada del usuario. Al igual que las acciones, todos los ActionForms deben heredar de una clase base. DynaBean se puede utilizar como alternativa para generar clases ActionForm, pero los desarrolladores deberán anular los javaBeans existentes. Struts2 utiliza propiedades de acción como propiedades de entrada, eliminando la necesidad de objetos de entrada. Struts2 también admite el modelo ActionForm, que es un objeto de formulario POJO y una acción 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. La funcionalidad basada en esquemas simplifica la relación entre etiquetas y objetos de entrada POJO.
6. Lenguaje de expresión
Struts1 está integrado con JSTL, por lo que se puede utilizar JSTL EL.
Struts2 también admite JSTL, pero el marco también admite el lenguaje de expresión más potente OGNL
7 Enlace de capa de expresión y valor de tipo
Struts1 utiliza JSP estándar. Mecanismos para vincular objetos al contexto de la página para su acceso.
Struts2 utiliza la tecnología "ValueStack" para que las etiquetas no tengan que combinar objetos de vista y presentación para obtener valores. La estrategia ValueStack permite reutilizar vistas en una variedad de tipos, que pueden tener el mismo nombre de propiedad pero diferentes tipos de propiedad.
8. Conversión de tipo
El ActionForm de Struts1 suele ser de tipo String. Struts1 implementa la conversión de tipos a través de Commons-Beanutils.
Struts2 implementa la conversión de tipos usando OGNL. El marco contiene convertidores para tipos básicos y tipos públicos.
9. Validación
Struts1 admite la validación manual a través del método de validación en ActionForm. También puede ampliar el marco de validación genérico para realizar la validación. Puede tener diferentes validaciones para una misma clase, pero no subobjetos asociados a validaciones.
Struts2 también admite la validación manual a través del método de validación, así como el marco de validación Xwork, que admite el encadenamiento de validación a subpropiedades utilizando validaciones definidas 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 en 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. Normalmente, se crean y utilizan diferentes pilas para diferentes operaciones según sea necesario.