¿Roo o no Roo? [cerrado]

Tenga en cuenta que Spring Roo y JBoss Seam no son directamente comparables, ya que JBoss Seam en sí mismo no proporciona la generación de aplicaciones CRUD mencionada en la pregunta. Sin embargo, JBoss Seam viene con la herramienta seam-gen, que proporciona esta funcionalidad. Por lo tanto, probablemente sería mejor ver JBoss Seam como comparable al marco de resorte y comparar la herramienta seam-gen con Spring Roo. Sé que esto tampoco es una comparación completa, pero eso está fuera de este tema, supongo. Lo necesita ser declarado es que en la respuesta a continuación, cuando me refiero a JBoss Seam, en realidad me refiero a JBoss Seam en combinación con la herramienta seam-gen.

Tanto Spring Roo como JBoss Seam (con seam-gen) hacen que la creación de aplicaciones CRUD sea realmente fácil, como por cierto otras soluciones Java full stack/scaffolding como Play Framework y RIFE también lo hacen. Si comparas los dos (Spring ROO y JBoss Seam con seam-gen) en qué tan rápido tienes un nuevo CRUD básico aplicación en funcionamiento, basada en una base de datos existente o mediante la adición de entidades y la definición de los campos y relaciones, supongo que no hay mucha diferencia. En mi experiencia puedes hacerlo en Spring Roo solo un (un poco) un poco más rápido, pero con ambos tienes la aplicación en menos de una hora (en caso de una base de datos existente) o en menos de (medio) un día (en caso de que tengas que agregar manualmente todas las entidades y relaciones).

Antes de continuar, el lector debe tener en cuenta que toda esta comparación se hizo sobre la base de mi humilde experiencia con ambas soluciones, y por lo tanto se basa en Spring Roo versión 1.1.0 y JBoss Seam 1.2 y 2.x. El lector también debe tener en cuenta que actualmente ya existe una excelente versión de Seam 3 (en realidad CDI (Weld) con complementos de módulo de Seam) que se basa en la especificación Java EE 6, pero que esta nueva versión de JBoss Seam ya no tiene la aplicación seam-gen y por lo tanto aún no tiene la funcionalidad con solo un par de comandos como Spring Roo y JBoss Seam 2.x e inferior tienen. Actualmente hay gente de JBoss trabajando en algo similar, llamado JBoss Forge , que parece muy prometedor pero que, a día de hoy, aún no ha tenido ninguna versión real y, por lo tanto, aún no es una opción, supongo.

Tanto Spring ROO como JBoss Seam (con seam-gen) crean una buena aplicación CRUD básica, aunque el diseño de interfaz de usuario predeterminado de la aplicación generada por Spring Roo parece un poco mejor en mi humilde opinión, pero como probablemente quieras reformular de todos modos, esto no es un gran argumento para ninguno de los dos. Las aplicaciones web creadas también difieren ligeramente en la funcionalidad ofrecida, pero en cuanto a la funcionalidad básica de CRUD y otras características básicas como la autenticación y la internacionalización, están a la par entre sí.

Creo que las principales diferencias y por lo tanto las razones para decidir por qué quieres ir, no están en el tiempo que lleva generar una aplicación CRUD básica ni en las aplicaciones CRUD básicas andamiadas, sino en cosas mucho más importantes como decisiones de arquitectura / diseño, uso, soporte, documentación, flexibilidad, capacidad de mantenimiento, puntos de extensión, etc. Por lo que a mí respecta, tanto Spring Roo como JBoss Seam son excelentes opciones para basar su aplicación web (de hecho, mi equipo ha creado una aplicación de producción con ambos), pero antes de tomar una decisión, debe mirar estas importantes diferencias y decide qué funciona mejor para ti. Por supuesto, la mejor manera de decidir, sería hacer una prueba de concepto por ti mismo con ambas opciones, pero si no tienes el tiempo y/o los recursos, aquí está lo que se me ocurre (desde la parte superior de mi cabeza) que son diferencias entre las dos y que podrían ayudarlo a decidir de cualquier manera:

• El sistema de construcción subyacente utilizado en Spring Roo es Maven, donde JBoss Seam utiliza Ant. Seam puede, por lo que sé, también se puede utilizar con maven, pero seam-gen por por defecto usa Apache Ant. Tenga en cuenta que JBoss Forge (reemplazo de seam-gen y en realidad más como Spring Roo) está utilizando Maven sin embargo.
• Spring Roo se basa en el framework Spring, mientras que JBoss Seam se basa en toda la pila Java EE 5 (Seam 3 utilizará la pila Java EE 6). Tenga en cuenta que JBoss Seam y la herramienta seam-gen usarán EJB 3.0 por defecto, pero esto es opcional y también puede optar por una solución none-EJB con JBoss Seam y la herramienta seam-gen.
• JBoss Seam (con seam-gen) utiliza la herencia básica OO para agregar funcionalidad básica a las clases generadas extendiendo las clases específicas de JBoss Seam. Esto agrega una dependencia de tiempo de ejecución a las clases específicas de JBoss Seam (y seam-gen). Spring Roo elige un enfoque totalmente diferente, generando ambos archivos fuente Java simples (sin extender las clases relacionadas con Spring) y anotando estas clases. Junto con los archivos fuente Java generados, Spring Roo también genera una o varias de las llamadas declaraciones inter-type (ITD) archivos, que son archivos específicos de AspectJ que contienen código fuente generado y anotaciones. Estos archivos ITD se entretejerán de forma completamente transparente en los archivos de clase generados en tiempo de compilación y, por lo tanto, no impondrán una dependencia de tiempo de ejecución.
• Los archivos generados por Seam pueden (y serán) actualizados por usted, pero si necesita regenerar los archivos con seam-gen, sobrescribirá sus cambios manuales, esto porque hará los cambios en los archivos generados por Seam-gen. Debido Enfoque de Spring Roo con ITD, realiza cambios en el archivo fuente Java que anulan el código fuente generado en los archivos ITD. Esto hace posible que Spring Roo regenere los ITD a medida que deja los cambios manuales, que están en el archivo fuente de Java, sin cambios.
• El uso de seam-gen está más inclinado a una generación/uso de una sola vez para configurar inicialmente el proyecto y comenzar a funcionar, mientras que Spring Roo se usa durante toda la vida útil del proyecto. proyecto.
• Spring Roo se puede eliminar de un proyecto, dejando un proyecto completamente operativo que ya no tiene dependencias en Spring Roo y, por supuesto, todavía se puede construir y extender de la manera que desee. La utilidad seam-gen no ofrece tal funcionalidad, aunque en el caso de seam-gen, por supuesto, nunca depende de seam-gen en sí, sino de un paquete de Seam específico de JBoss (llamado framework).
• JBoss Seam (con seam-gen) está dirigido principalmente para usar JSF como el web framework, mientras que Spring Roo se centra en Spring MVC y / o GWT como su web framework. JBoss Seam también tiene un buen soporte para Wickete, pero no con la herramienta seam-gen. Spring Roo también tiene un complemento Flex y se crean más complementos para otros marcos web en la comunidad, pero todavía no son tan buenos como los de Spring MVC y GWT.
• La documentación es excelente tanto para JBoss Seam como para Spring, pero para Spring Roo y la herramienta seam-gen carecen de la más avanzada documentación. Spring Roo por cierto también ofrece grandes consejos útiles en la línea de comandos shell.
• El soporte IDE para el enfoque JBoss Seam es mejor que para el enfoque Spring Roo. Ambas soluciones tienen un IDE específico basado en Eclipse y complementos (SpringSource Tool Suite para Spring Roo y JBoss IDE para JBoss Seam) y todos los demás IDE grandes (Netbeans en IntelliJ) tienen un gran soporte para los frameworks base, pero los IDE none-Eclipse (no completamente seguros para IntelliJ IDE tener un buen soporte para los ITD generados por By Spring Roo. Esto no es un problema en la compilación, pero proporciona problemas con intellisense y la funcionalidad relacionada con la finalización de código en estos IDE.

Aunque, por supuesto, hay muchas más diferencias entre estos dos grandes productos y ni siquiera he tocado cosas importantes como la capacidad de prueba, la curva de aprendizaje y el futuro de estos proyectos, espero que las viñetas anteriores ya puedan ayudar a las personas que están considerando estas dos soluciones, para tomar una decisión al menos un poco más fundada. Me gusta enfatizar una vez más que la mejor manera de tomar una decisión sigue siendo crear una prueba de concepto con ambos enfoques y ver qué mejor se adapta a usted.

Los puntos principales, en mi humilde opinión, que podrían darle una decisión fácil y rápida son las opciones entre la pila de primavera o la pila de Java EE, el soporte IDE, el marco Web y la 'adultez' de la solución. Así que si estás muy familiarizado con la pila de primavera (que supongo que eres, viendo que vienes de Grails), opta por Spring Roo ya que de lo contrario podrías perder bastante tiempo para familiarizarte con la pila de Java EE, incluyendo JSF (por supuesto, esto depende del tamaño de tu proyecto, pero asumiendo que no es un proyecto muy grande, el impacto de aprender nuevas técnicas podría ser demasiado grande para un solo proyecto). Si no puede o no quiere usar Eclipse y es realmente un apasionado de esto, supongo que JBoss Seam podría ser una mejor solución. Si desea utilizar JSF o Wicket, vaya por JBoss Seam, mientras que si desea usar Spring MVC o GWT, use Spring Roo (para otros marcos web probablemente no importa qué elija, aunque Spring roo podría ser una mejor solución). Y si la' adultez ' es tu principal punto de decisión, supongo que será mejor que uses JBoss Seam. En general, decidir entre los dos puede ser muy difícil, pero al menos debes saber que ambas soluciones son realmente geniales y te ayudarán mucho, de cualquier manera.

Por cierto, asegúrese de mantener un tenga en cuenta el proyecto JBoss Forge, ya que la solución actual seam-gen se reemplazará en un futuro próximo con este proyecto prometedor.