Hay que decir que cuando Craig McClanahan liberó Struts en el año 2000, había mejores opciones en cuanto a frameworks MVC open source. A mí me encantó el hecho de que alguien le viese salida al tema de los custom tags de JSP, que llevaba ya tiempo, y prueba de ello es que los dos becarios que trabajaban conmigo en aquel momento realizaron su proyecto de fin de carrera precisamente con esa tecnología.
JSP, que era la presentación soportada, era un estándar, y era fácil encontrar desarrolladores que lo conocieran. Además, el que se constituyera como proyecto Apache garantizaba una comunidad y una seriedad en el soporte y en el roadmap. Por eso triunfó, hasta convertirse en un estándar de facto, y ser el framework web MVC más usado en Java.
Pero hay que decirlo, Struts tenía defectos muy importantes, sobre todo dos. Primero, cada acción solía implicar la creación de dos clases (la acción y el bean de formulario). Segundo, el desarrollo era muy acoplado al framework con acciones que heredaban de sus clases y con métodos que recibían objetos propios de Struts, además de objetos request, response,… Para evitar el acoplamiento, había que usar algún patrón J2EE, como Business Delegate, para llevar el negocio a zonas de código neutras que pudieran ser reutilizables, y de esa forma poder, por ejemplo, publicar la funcionalidad como servicio web o cambiar la presentación por un GUI Swing o SWT.
Como digo, existían opciones mejores, tales como ActionFramework, que basaba su presentación en plantillas (primero WebMacro y luego también Velocity) y permitía usar componentes Java tipo POJO, reutilizables para varias acciones, cada una asociada a un método distinto. Pero estas opciones tenían una comunidad muy escasa y a menudo estaban desarrolladas por una sola persona.
El creador de iBATIS, Clinton Begin, percibió estas carencias de Struts y las intentó subsanar, con una contribución llamada BeanAction, que no llegó a incorporarse oficialmente al proyecto, pero que él sí utilizó en la aplicación JPetStore que sirve de demo a su framework de persistencia. BeanAction, como su nombre ya sugiere, permite usar una sola clase para hacer de bean de formulario y de acción. Las acciones también se mapean a métodos, de forma que podemos tener una misma clase que gestione el login, el registro, el logout,… todo lo relacionado con los usuarios. El código que queda usando esta capa extra es bastante potable y es de tipo POJO, pues los métodos de acción no reciben argumentos y devuelven un String, que servirá para indicar qué presentar o a qué otra acción redirigir.
He usado BeanAction ya en varias ocasiones, con buenos resultados. Pero también he recibido críticas, de compañeros que no lo veían como “auténtico Struts”. Precisamente yo pensaba que ésa había sido la filosofía de Struts desde el principio, pero que se había perdido en el camino.
Hace menos de un año, los proyectos Struts y Webwork unieron fuerzas, algo que es digno de admiración, pues en el mundo open source muchas veces las vanidades pesan demasiado y es difícil dejarlas a un lado y trabajar por la comunidad. Resultado de ese esfuerzo es Struts 2, un framework más pesado pero también más potente, con una mejor integración con Spring, característica que es básica en la actualidad.
Me alegró mucho ver que Struts 2 presenta exactamente el mismo modelo de acciones que Struts + BeanAction, aunque con más servicios y mayor potencia, como es lógico.
Al final, sí que era “auténtico Struts”.
El problema de tener que pegárselas en el modo vista con los ActionForm y en el modelo con nuestros simpáticos Beans o Pojos ha sido siempre un grano en el culo en todos los desarrollos en los que he participado.
Por eso en el análisis de clases siempre incluía unas clases intermedias que me gustaba llamar ‘Parsers’ con métodos parseToForm y parseToBean del siguiente modo:
* Parser.parseToForm( Bean:bean ) : ActionForm
* Parser.parseToBean( ActionForm:form ) : Bean
Claro está: un Parser para cada pareja Bean-ActionForm de la plataforma.
Me dices que los BeanAction resuelven estas acciones de manera genérica y automática.. pues Óle
Hola Fernando
Sí, Bean Action soluciona ese problema, pero es un código totalmente descontinuado. Yo te recomendaría pasar ya a Struts 2, que te da una serie de servicios bastante interesantes, y además te permite usar OGNL en la presentación, un lenguaje más potente que JSTL + EL (aunque no tan elegante), que es capaz de recorrer toda la pila de objetos (de la request, de la sesión, del contexto) y encontrar el valor que se desea recuperar, sin necesidad de cualificarlo ni indicar el ámbito.
Un saludo
He encontrado tu blog de javijava
(habramos un poco ayer en after crosstalent) una cosa te queria preguntar tu que controlas java, conoces el CMS java http://www.liferay.com ?
pregunta a todos: struts sera reemplazado por spring? todoel mundo dice eso y la verdad yo mucha idea no tengo porque recien estoy empezando con ese lenguaje (solo en estos años me he dedicado al sap), me gustaria preguntarle a uds, pues veo que por lo menos algo de struts saben!
ah otra cosilla, aqui les dejo un foro de java que encontre, quiza les sea de ayuda quiza no.. pero se los paso
http://www.forodejava.com
suerte!
Struts y Spring son dos cosas muy diferentes. El primero es un framework MVC de programación web. El segundo, uno de injección de dependencias.
Lo que pasa es que Spring también tiene un framework MVC (Spring MVC), que está siendo usado por bastante gente. Sin embargo, yo apuesto más por Struts 2, pues me parece myy potente.
Lo verdaderamente importante es la integración entre estos frameworks, y esa funciona muy bien.
Es cierto … en Struts, crear un Action para cada formulario resulta un poco tedioso… pero te permite manipular la enviado por el usuario antes de que llegue al form, en incluso validar su input (los métodos reset y validate). Lo de crear un Action por formulario si me parece excesivo (aunque es en pro de la high cohesión…no?), pero he encontrado en múltiples sitios que le meten mano al ActionServlet para poder trabajar con varios métodos en un mismo action. En fin, yo trabajo cómodamente con Struts…pero sería bueno echarle un ojo a los otros MVC frameworks
Struts a mejora mucho desde su version anterior, quepara su tiempo era buena pero con el pasar del tiempo aparecieron nuevas alternativas. Pero con la version 2 su alternativa para su eleccion en un desarrollo entra en competencia.
Aqui les comparto mis 2 BLOG encontraran temas interesantes ahi.
http://frameworksjava2008.blogspot.com
http://viviendoconjavaynomoririntentandolo.blogspot.com/