usar - todo sobre grails




Grails vs Roo: ¿por qué SpringSource está impulsando dos tecnologías muy similares? (6)

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.


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.


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