tutorial - Grails vs Roo: ¿por qué SpringSource está impulsando dos tecnologías muy similares?

por que usar grails (8)

SpringSource (ahora VMWare) tiene dos tecnologías muy similares: Grails y Spring Roo. He estado utilizando Grails, pero veo que SpringSource está trabajando activamente en algo que compite por esa tecnología y eso me preocupa por el futuro de Grails.

¿Alguien sabe cómo se relacionan estas tecnologías, se fusionarán o una de ellas será abandonada?

Además, ¿hay diferencias técnicas importantes entre Grails y Roo?

¡Vi algunos comentarios en las listas de correo de Grails que indicaban que los autores creían que Roo existe solo como un trampolín para Grails! Sin embargo, personalmente estoy considerando un posible cambio de Grails a Roo. Creo que la principal diferencia es entre los lenguajes dinámicos y los tipados estáticos, para mí esto es enorme. Me encantan muchas funciones de Grails, pero prefiero la compatibilidad con IDE y la verificación en tiempo de compilación de un lenguaje estáticamente tipado. Algunos otros sienten exactamente lo contrario, por lo tanto caballos para los cursos. Dicho esto, el groovy estático actualmente se encuentra en gran desarrollo, así que quién sabe lo que depara el futuro.

Ben Alex de SpringSource habla sobre Roo en esta entrevista y le preguntan sobre Grails vs Roo. La principal diferencia además de usar diferentes idiomas (Groovy vs Java como otros mencionaron) es que Roo es principalmente una herramienta de tiempo de desarrollo y Grails está más involucrado en el tiempo de ejecución.

El objetivo de SpringSource es hacer que las personas construyan, ejecuten y administren soluciones basadas en Spring lo más rápido y fácil posible. Tenemos tanto Grails como Spring Roo porque nos preocupamos profundamente por la productividad del desarrollador e, indudablemente, ambas herramientas brindan un impulso serio a lo que los equipos pueden lograr durante la primavera.

Tenemos ambas tecnologías porque Roo y Grails son muy diferentes a nivel filosófico y de implementación (como ya se señaló en las otras respuestas). Cada tecnología aborda su lenguaje principal (Java o Groovy) y el modelo operativo (tiempo de desarrollo o tiempo de ejecución) con la filosofía de "¿cómo hacemos que la propuesta de valor sea increíblemente buena usando este lenguaje y la combinación de modelo operativo?". Como tal, verá que cada tecnología adopta un estilo diferente que maximiza esa combinación (Java + Dev-time de Roo o Groovy + Runtime de Grail) y los beneficios acordes.

Estas diferencias son realmente muy positivas, porque significan que la comunidad Spring puede elegir qué "sabor" de la solución de productividad prefieren. Si bien estas diferencias iniciales sobre la elección de idioma y el funcionamiento / tiempo de desarrollo son evidentes, la elección de Grails o Roo también se extiende a consideraciones más sutiles como las tecnologías predeterminadas utilizadas, modelo de interacción del usuario, soporte IDE, dependencias, estándares, hoja de ruta, extensiones, etc. Casi todas estas diferencias son una consecuencia natural de buscar la mejor solución para un estilo de lenguaje en particular.

Nuestro mejor consejo es considerar ambas soluciones. Cada uno tiene sus puntos positivos, pero existen diferencias entre los dos que harán que su experiencia general sea mejor con una tecnología u otra en un contexto determinado. Ambas guías de referencia detallan los beneficios respectivos de cada solución . Por supuesto, recuerde que la inversión de tiempo es mínima para probar ambos. En 10 minutos puede construir un proyecto en Roo o Grails, así que pruébelo y vea qué se siente más natural para usted dado sus antecedentes específicos y las necesidades del proyecto.

En realidad no son tan similares. Roo lo hace mágico en el tiempo de compilación, donde Grails lo hace en tiempo de ejecución. Debido a que los proyectos de Roo no reciben ningún impacto de rendimiento en el tiempo de ejecución.

No veo cómo podrían fusionarse, ya que Grails se basa en Groovy y Roo en Java.

Grails y Roo son muy diferentes. La primera gran diferencia es el lenguaje utilizado. Si bien puedes escribir código Groovy como el código Java tradicional, aún necesitas las dependencias Groovy para ejecutar aplicaciones Grails. Para ser lo más productivo posible en Grails, también necesita conocer las funciones de Groovy que actualmente no forman parte de Java, como Closures. Otra diferencia es la filosofía que los marcos toman para generar código. Grails genera muchos métodos en tiempo de ejecución mientras Roo los genera a petición durante el proceso de desarrollo. Roo no tiene detrás de las escenas la aceptación mágica para el uso de la programación orientada a aspectos, y usted puede ver todo el código que genera Roo. Por ejemplo, en Roo debe usar un comando para que genere métodos de búsqueda dinámica como findByBook () y luego vea el código generado en los archivos .aj. En Grails, el método findByBook () se crea en tiempo de ejecución y no se puede ver el código generado. Roo también le permite dejar de usar el marco si elige mientras continúa teniendo una aplicación en ejecución al fusionar todo el código generado en archivos .java normales. Entonces no tiene dependencias en ninguna biblioteca Roo ni en tiempo de ejecución ni en tiempo de diseño. Si decides que no te gusta Grails, no hay forma de que dejes de utilizar el framework mientras sigas teniendo una aplicación en funcionamiento.

IMO los dos no son muy similares. Aunque hay similitudes, las siguientes son diferencias significativas:

Roo usa "Stock-Standard Java", Grails se basa en Groovy
Grails es un framework web, Roo no es

Roo es muy similar al sistema de línea de comandos de Grails (por ejemplo, los comandos del tipo create-app , create-domain-class , test-app encuentran en Grails). No me sorprendería ver algo de "polinización cruzada" entre esta parte del framework de Grails y Roo.

La principal diferencia es que Roo es un marco puro de Java, mientras que Grails aprovecha tanto Groovy como Java. Ambos se basan en las bibliotecas principales de Spring y hacen uso de las populares bibliotecas de código abierto de Java.

Esta pregunta se formuló cuando se anunció Roo y Graeme Rocher (líder de Grails) dice que ambos marcos tienen un lugar en Spring y son compatibles por igual.

En todo caso, creo que Grails tiene un futuro mejor que Roo. Me encanta desarrollar con él y no veo ninguna desventaja de que no sea Java puro.

Teníamos un requisito en el que teníamos una aplicación en producción y se desarrolló en Spring MVC y la velocidad de desarrollo de nuevas funciones fue lenta. Tuvimos que explorar marcos alternativos como Grails y Roo. Personalmente, pasé cerca de un mes explorando cuál era mejor.

Si desea ver los detalles del análisis, visite @ http://krishnasblog.com/2012/05/08/roo-vs-grails/ 2012/ http://krishnasblog.com/2012/05/08/roo-vs-grails/ 08/ http://krishnasblog.com/2012/05/08/roo-vs-grails/ vs- http://krishnasblog.com/2012/05/08/roo-vs-grails/

Exploramos las siguientes características en ambos y nuestros hallazgos a continuación. El veredicto final no estamos seguros de que usemos ninguno, todavía estamos explorando