Struts1 vs Struts2

La siguiente es una comparación tomada y traducida de la página de Rose India, un pequeño articulo que anima a los desarrolladores de Struts1 a comenzar a usar Struts2
Les pongo la liga de la página.

También puedes encontrar muchos otros ejemplos de programación en Java.

Struts1 vs Struts2

Clases Action

Struts1
Se Requiere extender de la una clase Action abstracta. El problema común en Struts1 es que se programan clases abstractas en lugar de interfaces.
Struts2
Un Action puede implementar una interfaz Action, además de otras interfaces que le permitan integrar mas servicios. Struts2 provee de una clase base ActionSupport que implementa las interfaces comúnmente usadas. Además esta interfaz no es requerida. Cualquier POJO con un método de ejecución puede ser usado como Action en Struts2

Modelo de hilos

Struts1
Las Actions implementan el patrón singleton y deben ser thread-safe por lo que puede haber solo una instancia de una clase para manejar todas las peticiones para ese Action. La estrategia singleton pone restricciones sobre lo que podemos hacer con los Actions de Struts1 y se requiere un cuidado extra para desarrollar. Los recursos usados para los Actions deben ser thread-safe o sincronized.
Struts2
Los objetos Action son instanciados por cada petición, por lo que no hay problemas de tipo con la seguridad de hilos. En la práctica, los contenedores de servlets generan muchas instancias, así que un objeto mas no representa problemas de rendimiento y de impacto en el garbage collection

Dependencia de los Servlets

Struts1
Las Actions tiene dependencias de la API de Servlets dado que HttpServletRequest y HttpServletResponse son pasados al método excecute cuando la Action es invocada.
Struts2
Las Actions no están acopladas al contenedor. A menudo el contexto de los servlets esta representado por simples Maps, permitiendo a las Actions ser probadas de forma aislada. Las Actions de Struts2 puede mantener el uso del request y el response si se requiere. De cualquier forma, otros elementos de la arquitectura reducen o eliminan la necesidad de acceder a HttpServetRequest o a HttpServletResponse directamente.

Manejo de pruebas

Struts1
El principal obstáculo para las Actions de Struts1 es que la ejecución de métodos requiere de la API de Servlets. Una extensión de terceras partes, como Struts TestCase, que ofrece un conjunto de simuladores para objetos de Struts1.
Struts2
Las Actions pueden ser probadas instanciado la Action, estableciendo propiedades e invocando métodos. El soporte a la Inyección de Dependecias permite hacer las pruebas de forma simple.

Recolección de datos de entrada

Struts1
Es necesario el uso de un objeto ActionForm para capturar las entradas. Como las Actions, todos los ActionForm deben extender de una clase. Como algunos JavaBeans no implementan de ActionForm los desarrolladores a menudo crean clases redundantes para capturar a las entradas. Los DynaBeans pueden ser usados de forma alternativa para crear clases ActionForm convencionales, pero, los desarrolladores deben JavaBeans existentes.
Struts2
Usa las propiedades de las Actions para manejar las entradas, elimina la necesidad de un segundo objeto de entrada. las propiedades de entrada pueden ser objetos de una amplia variedad que incluso pueden tener sus propias variables. Las propiedades de las Action pueden usadas por la pagina Web por medio de los TagLibs. Struts2 soporta incluso el patrón de ActionForm, asi como objetos y acciones POJO. Tipos de objetos, incluyendo negocios o objetos de dominio, pueden ser usados como objetos en entrada y salida. La característica ModelDriven simplifica las referencias por taglib a objetos POJO.

Lenguaje de Expresiones

Struts1
Esta integrado con JSTL, así que usa el JSTL EL. El EL tiene una traza grafica de objetos básica y una relativamente pobre colección e indexación de soporte a propiedades.
Struts2
Puede usarse JSTL, pero el marco de trabajo soporta ademas un lenguaje de expresiones mas poderoso y flexible llamado «Object Graph Notation Language» (OGNL)

Vinculación de objetos de la vista

Struts1
Usa el mecanismo estándar de JSPS para el vincular objetos en el contexto de las páginas.
Struts2
Usa una tecnología llamada «ValueStack» donde los taglibs pueden acceder a valores sin estar acoplados a la vista donde el tipo de objeto se renderea. La estrategia del «ValueStack» permite reutilizar vistas gracias al rango de variables que pueden tener el mismo nombre pero tipo diferente tipos de propiedades.

Conversion de tipo

Struts1
Las propiedades de los ActionForm son usualmente Strings. Struts1 usa comúnmente Commons-Beanutils para la conversión de tipos. Las conversiones son configurables por clase y no por instancia.
Struts2
Usa OGNL para la conversión de tipos. El marco de trabajo incluye convertidores para objetos básicos y tipos primitivos.

Validación

Struts1
Soporta validación manual por medio de métodos en el ActionForm, o a través de una extensión de los Commons Validator. Las clases pueden tener diferentes contextos de validación para la misma clase, pero no pueden encadenar validaciones en sub objetos.
Struts2
Soporta validación manual por medio de métodos y por el marco de trabajo XWork Validation. El XWork soporta encadenamiento de validaciones en las subpropiedades usando las validaciones definidas para las propiedades de la clase y el contexto de validación.

Control de la ejecución del Action

Struts1
Soporta Request Porcessors (Ciclos de vida) separados por cada módulo, pero todas las Actions en el módulo deben compartir el mismo ciclo de vida.
Struts2
Soporta ciclos de vida diferentes, uno por Action por medio de la pila de interceptores. Pilas configurables pueden ser creadas y usadas con diferentes Actions si es necesario.

Esta es una tabla excelente para observar solo algunas de las mejoras en Struts2, sin embargo yo pondría especial énfasis en las ventajas que ofrecen los interceptores en Struts2, ya que permiten aislar gran parte de operaciones de control que son comunes en todas las aplicaciones Web, entre ellas una muy importante, el manejo de la sesión y la restricción de acceso a usuarios con permisos. Aislando estas operaciones es mas fácil reutilizar el código en otras aplicaciones.
Además los interceptores que vienen por default en el marco de trabajo resuelven y aislan una gran cantidad trabajo, como carga de archivos, validaciones, intenacionalizacion y mas. Solo tendremos que usar lo que los desarrolladores de Struts2 ponen a nuestra disposición.

Espero que este post les sea de utilidad, no olviden dejar sus comentarios si tienen alguna duda sobre los ejemplos o si tienen alguna sugerencia para el blog.

Hasta el próximo post.