¿Diferencia entre Struts 1 y Struts 2?

Question

He estado usando struts 2, pero por algunas razones estoy cambiando (hacia atrás) a Struts 1. Me gustaría saber las principales diferencias entre ellos, como sobre las disponibilidades programáticas y los flujos generales.

Answer 1

Here es una respuesta rápida y completa. En otras palabras, si se puede, se olvide de puntales y utilizar sólo Struts2 ...

Answer 2

¿Cuáles son las razones que te obligaron a volver a struts1 que ya no está en desarrollo activo?

puede haber algo de uno puede ayudar aquí en la solución de sus diferencias con respecto a razones pasar por el siguiente hilo Struts2 Vs Struts1

También sugerimos realizar una búsqueda SO para obtener más detalles. Lo que sé es que el diseño y el flujo de trabajo de Struts2 son completamente diferentes a los de struts1 y fue desarrollado para tener en cuenta también las limitaciones que tiene struts1.

Answer 3

Veamos las diferencias funcionales entre los componentes y puntales y puntales 1.x 2.x

In struts 1.x front controller is ActionServlet 
    In 2.x front controller is FilterDispatcher 

In struts 1.x we have RequestProcessor class 
    In 2.x we have Interceptors instead RequestProcessor will see about this concept later just remember as of now 

In struts 1.x we have multiple tag libraries like, html, logic, bean..etc 
    In 2.x we do not have multiple libraries, instead we have single library which includes all tags 

In struts 1.x the configuration fine name can be [any name].xml and we used to place in web-inf folder 
    In 2.x the configuration file must be struts.xml only and this must be in classes folder 

In struts 1.x we have form beans and Action classes separately 
    In 2.x form bean, Action classes are combinedly given as Action class only, of course we can take separately if we want ;) 

In struts 1.x properties file must be configured in struts-config.xml 
    But in 2.x we need to configure our resource bundle(s) in struts.properties file 

In struts 1.x we have programmatic and declarative validations only 
    In 2.x we have annotations support too along with programmatic and declarative validations 

diferencias funcionales

In struts 1.x declarative validations are done by using validation frame work 
    In 2.x, declarative validations are done by using xwork2 frame work by webwork the reason being, its support valuations through Annotations 

In struts 1.x an Action class is a single ton class, so Action class object is not a thread safe, as a programmer we need to make it as thread safe by applying synchronization 
    In 2.x an Action class object will be created for each request, so it is by default thread safe, so we no need to take care about safety issues here 

In struts 1.x we have only jsp as a view technology 
    In 2.x we have support of multiple view technologies like velocity, Freemarker, jasper reports, jsp bla bla 

In struts 1.x Action class is having servlet dependency, because in execute() method accepts req, res parameter right ! so. 
    In 2.x Action class doesn’t have any servlet dependency, because its execute() method doesn’t accepts any parameters, however we can access all servlet objects with dependency injection 

Answer 4

Comparación de Struts 1 y 2 por los creadores de puntales (Apache software Foundation)

Comparing Struts 1 and Struts 2

Aquí está el contenido disponible en el enlace mencionado anteriormente, en caso de que decidan cambiar el enlace o eliminar la página en el futuro.

1. clases Action
   

   • Struts 1
     Requiere clases de acción para extender una clase base abstracta. Un problema común en Struts 1 es la programación de clases abstractas en lugar de interfaces.
     
   • Struts 2
     La acción puede implementar una interfaz de acción, junto con otras interfaces para habilitar servicios opcionales y personalizados. Struts 2 proporciona una clase base ActionSupport para implementar interfaces de uso común. Sin embargo, la interfaz de acción es no es necesario. Cualquier objeto POJO con una firma de ejecución se puede usar como un objeto de acción de Struts 2.

2. modelo de subprocesos
   

   • Struts1
     acciones son únicos y deben ser flujos seguros ya que sólo habrá una instancia de una clase para manejar todas las peticiones de esa acción. La estrategia de singleton impone restricciones sobre lo que se puede hacer con Struts 1 Actions y requiere un cuidado especial para desarrollarse. Los recursos de acción deben ser seguros para subprocesos o sincronizados.
     
   • Struts 2
     Los objetos de acción se instancian para cada solicitud, por lo que no hay problemas de seguridad de subprocesos. (En la práctica, contenedores de servlets generan muchos objetos de usar y tirar por solicitud, y un objeto más no impone una recolección de basura penalización en el rendimiento o el impacto.)

3. servlet Dependencia
   

   • Struts 1
     Las acciones tienen dependencias en la API de servlet ya que HttpServletRequest y HttpServletResponse se pasan al método de ejecución cuando se invoca una acción.
     
   • Struts 2
     Las acciones no están acopladas a un contenedor. En la mayoría de los casos, los contextos de los servlets se representan como mapas simples, lo que permite probar las acciones de forma aislada. Las acciones de Struts 2 aún pueden acceder a la solicitud y respuesta originales, si es necesario. Sin embargo, otros elementos arquitectónicos reducen o eliminan la necesidad de acceder a HttpServetRequest o HttpServletResponse directamente.

4. capacidad de prueba
   

   • Struts1
     Un obstáculo importante para las pruebas Struts1 acciones es que el método de ejecución expone la API Servlet. Una extensión de terceros, Struts TestCase, ofrece un conjunto de objetos simulados para Struts 1.
   • Struts 2
     Admite la creación de diferentes ciclos de vida por acción a través de Interceptor Stacks. Las pilas personalizadas se pueden crear y usar con diferentes Acciones, según sea necesario.
     Struts 2 Las acciones se pueden probar creando una instancia de Acción, estableciendo propiedades y aplicando métodos. La compatibilidad con Dependency Injection también simplifica las pruebas.

5. cosecha de entrada
   

   • Struts1
     Utiliza un objeto ActionForm para capturar la entrada. Al igual que las Acciones, todos los ActionForms deben extender una clase base. Como otros JavaBeans no se pueden usar como ActionForms, los desarrolladores a menudo crean clases redundantes para capturar datos. DynaBeans se puede usar como alternativa a la creación de clases convencionales de ActionForm, pero, también aquí, los desarrolladores pueden redesconectar los JavaBeans existentes.
   • Struts 2
     Utiliza propiedades de acción como propiedades de entrada, eliminando la necesidad de un segundo objeto de entrada. Las propiedades de entrada pueden ser tipos de objetos ricos que pueden tener sus propias propiedades. Se puede acceder a las propiedades de Acción desde la página web a través de los taglibs. Struts 2 también admite el patrón ActionForm, así como los objetos de formulario POJO y las acciones POJO. Los tipos de objetos enriquecidos, incluidos los objetos comerciales o de dominio, se pueden usar como objetos de entrada/salida. La función ModelDriven simplifica las referencias taglb a objetos de entrada POJO.
6. Expresión Idiomas
   
   • Struts1
     Se integra con JSTL, por lo que usa el JSTL EL. El EL tiene un recorrido básico de gráfico de objetos, pero una colección relativamente débil y soporte de propiedades indexadas.
     
   • Struts 2
     Puede usar JSTL, pero el marco también admite un lenguaje de expresión más potente y flexible llamado "Object Graph Notation Language" (OGNL).
7. Valores de encuadernación Into Vistas
   
   • Struts1
     utiliza el mecanismo estándar de JSP para vincular objetos en el contexto de la página de acceso.
     
   • Struts 2
     Utiliza una tecnología de "ValueStack" para que los taglibs puedan acceder a los valores sin acoplar su vista al tipo de objeto que está renderizando. La estrategia ValueStack permite la reutilización de vistas en un rango de tipos que pueden tener el mismo nombre de propiedad pero diferentes tipos de propiedad.
     
8. Tipo de conversión
   
   • Struts1
     propiedades ActionForm son por lo general todas las cadenas. Struts 1 usa Commons-Beanutils para conversión de tipo. Los convertidores son por clase y no configurables por instancia.
     
   • Struts 2
     Utiliza OGNL para conversión de tipo. El marco incluye convertidores para tipos de objetos básicos y comunes y primitivas.
     
9. de validación
   
   • Struts 1
     Soporta validación manual a través de un método de validación en el ActionForm, oa través de una extensión de la Commons validador. Las clases pueden tener contextos de validación diferentes para la misma clase, pero no pueden encadenarse a validaciones en subobjetos.
     
   • Struts 2
     Admite la validación manual mediante el método de validación y el marco de XWork Validation. El Xwork Validation Framework admite la validación de encadenamiento en sub-propiedades usando las validaciones definidas para el tipo de clase de propiedades y el contexto de validación.
     
10. control de la acción de ejecución
    
    • Struts1
      compatible con los procesadores solicitud por separado (ciclos de vida) para cada módulo, pero todas las acciones en el módulo debe compartir el mismo ciclo de vida.
    • Struts 2
      Admite la creación de diferentes ciclos de vida por acción a través de Interceptor Stacks. Las pilas personalizadas se pueden crear y usar con diferentes Acciones, según sea necesario.