java - example - grails tutorial español

¿Vale la pena Grails? (15)

Esto es medio despotricado, mitad pregunta.

¿Vale la pena usar Grails? Estoy tratando de desarrollar una aplicación web basada en una base de datos relativamente simple. Mi experiencia es en Java, así que, naturalmente, Grails parecía una buena opción. Al principio pensé en usar Spring, JPA e Hibernate, pero lo he usado anteriormente y me he encontrado con todo tipo de tediosas configuraciones y trabajos de codificación. Grails se anuncia a si mismo resolviendo esto.

Mi mayor frustración con Grails son todas las pequeñas cosas que no funcionan. Lo que quiero decir es que no funciona como uno intuiría que debería. Es muy difícil en los bordes. Me encuentro con problemas constantemente. A veces es mi falta de comprensión de Grails, otras veces descubrí errores legítimos de Grails.

Un problema importante es la falta de buena integración de Eclipse. Hay un complemento de Groovy y Grails, pero no hace mucho más que resaltar la sintaxis. Llamar a Groovy desde Java y viceversa es muy doloroso de configure . No tener un buen soporte IDE es un gran fastidio.

Lo que sucede es que me siento tratando de desarrollar mi aplicación web. Al final del día, me doy cuenta de que he pasado cerca del 85% del día depurando problemas relacionados con Grails. Si no se trata de problemas de Eclipse, se trata de una carga ansiosa , de ir a la vista , de relaciones uno a muchos , de un extraño comportamiento de errores de archivos vacíos , de un extraño error de propiedad / obtención : simplemente sigue y sigue. Esto es solo una muestra de los problemas con los que me encontré hoy. Mi última reunión con Grails produjo un montón de problemas diferentes.

A veces me pregunto si vale la pena. Tengo curiosidad si otros han experimentado esto. ¿Hay personas que realmente usan Grails para producir de manera productiva una aplicación web? ¿Hay otros marcos para el desarrollo web rápido que debería considerar?

¡Estoy totalmente contigo! Grails todavía se siente tan rudo en los bordes que es casi una broma compararlo con Rails. Si al menos el informe de errores fue un poco mejor. Pero creo que probablemente también se deba a la gran cantidad de bibliotecas que usa debajo de las carátulas. Una palabra: stacktrace! Tampoco soy un gran admirador del enfoque model-> db (Rails tiene db-> modelo). El andamio también deja mucho espacio para mejoras. Entonces "no se requiere reiniciar" tampoco funciona como se anuncia. (No estoy seguro de qué es peor, tener que reiniciar todo el tiempo o, a veces, encontrar comportamientos extraños que desaparecen cuando reinicias). Y no me hagas comenzar a usar GORM. (Cuando lleva horas encontrar una forma de lo que hubiera sido un simple SQL, empiezas a preguntarte si todo este ORM realmente te ahorra tiempo) Tal vez mientras sea simple.

Quiero decir: sigue siendo una de las mejores opciones de un marco cuando vienes del mundo de Java. (Tantas tonterías inútiles que se llaman a sí mismas frameworks web) ... tiene potencial. Solo desearía que no se hubiera construido sobre tantas otras cosas complejas.

De todos modos, esperemos que estas cosas se clasifiquen. Por el momento estoy acechando en playframework.org que también se ve muy ingenioso y prometedor.

Contamos con un equipo de 12 personas, todos experimentados desarrolladores senior de Java que aprendieron Grails desde 0.6B y todavía estamos trabajando en proyectos basados en Grails. No volvería a Java voluntariamente, y todos estamos aliviados de haber roto la parte posterior de cómo llegar a un lugar rápido con una aplicación de Grails.

Fue una lucha, no fue fácil y hubo / hay frustración.

Sin embargo, entregamos algo muy rápidamente debido a nuestros esfuerzos continuos. Hay errores, muchos de los cuales tienen soluciones.

He oído hablar de varias instancias de desarrolladores que son buenos en Java y que intentan sumergirse en encantamientos profundos y complejos de los proyectos de Grails. Evitamos todo Java y fuimos puros: Grails y Groovy. Nos aseguramos de que empezáramos de manera simple, desarrollamos la complejidad de la manera más manejable y práctica posible. No nos atrevimos a sumergirnos en el extremo más profundo y esperar que nuestro conocimiento de Java fuera suficiente para llevarnos.

Finalmente creamos algo enorme y complejo que funcionó fabulosamente y lo hizo mucho más rápido que escribir la versión pura de Java / Spring / Hibernate; y eso sin un soporte IDE decente y una situación mucho peor en términos de errores que en la actualidad.

En cuanto al soporte de Eclipse, el único IDE real para Grails / Groovy es Intellij: el soporte de Eclipse está muy por detrás, por desgracia: era un amante de Eclipse y estoy lejos de convertirme en un Intellijy: el soporte de Grails / Groovy destruye todo lo demás aunque.

Sí, Grails es inmaduro comparado con Spring quizás. O Hibernate. Y apostaría a que en los primeros 1.5 años de su existencia estuvieron igualmente llenos de problemas.

El hecho de ser así le impone la responsabilidad de cuidar de mantener la complejidad al mínimo absoluto, hacer una prueba cuidadosa primero (en nuestra opinión) y desarrollar la complejidad gradualmente y con cuidado.

No hay una solución de código rápido con Java una vez que involucras a Spring / Hibernate en la pila. La complejidad que encarna Grails es un reflejo de la propia complejidad de Spring / Hibernate. Si crees que es mejor que dediques tiempo a hacerlo con Java puro, no diría lo contrario. Todavía tengo mis WTF, pero ahora que la curva de aprendizaje ha quedado atrás, creo que seguiré apostando por Grails.

Creo que el apoyo de Spring a Grails va a ser un gran impulso. Si alguien puede moverlo más allá de CRUD en la web, son esos tipos.

También creo que está llegando a una masa crítica. Hay varios libros nuevos que llegarán al mercado en 2009. Creo que ayudarán a la tasa de adopción.

Disfruto mucho escribiendo aplicaciones de Grails por dos razones:

No tengo que usar Java
Puedo usar Java

Creo que después de haberse familiarizado con Grails uno hace sus cosas de manera muy rápida y elegante.

Tanto para el lado positivo. El lado negativo es el rendimiento, que me golpea en dos aspectos: implementación y desarrollo impulsado por test.

No he logrado ejecutar más de 3 aplicaciones de Grails en un único servidor (alquilado), porque alcanzo rápidamente los límites de memoria y rendimiento. Simplemente hay demasiados marcos incluidos.

Además, el testarrero de los griales no vale ese nombre. Cuando realizo pruebas unitarias, deben hacerse en un instante, no en 10 a 20 segundos. Así que me encuentro todo el tiempo escribiendo lógica empresarial en Java simple, porque puedo probarlo mucho más rápido. Pero supongo que esto se puede abordar con una mejor integración en el IDE (eclipse).

Encuentro que la mayor ventaja de Grails es que ya no tengo que preocuparme por la base de datos: el esquema se crea / actualiza automáticamente y la persistencia se realiza en gran medida para mí (no más consultas de escritura SQL). Esto es un gran alivio. La otra cosa que es bastante agradable es que una vez que estableciste las plantillas para controladores y vistas, agregar nuevos objetos de dominio es bastante rápido. Aunque sospecho que hará cambios continuos para sus puntos de vista al menos, ajustándolos a los existentes.

En cuanto al IDE, parece que IntelliJ es la mejor opción, pero me complace usar Netbeans 6.5. Utilizo MyEclipse para todos los demás desarrollos, pero Netbeans ahora tiene mejor soporte de Grails.

Era un usuario de Eclipse antes de comenzar a usar Grails. Pronto fue evidente que no iba a ser suficiente. Así que probé Intellij y NetBeans. En ese momento, Intellij era mejor en lo que respecta a Groovy y Grails. Sin embargo, NetBeans era gratis y eso lo hizo lo suficientemente bueno para mí. Desde entonces, los tres han lanzado nuevas versiones o nuevos complementos. Todavía estoy usando NetBeans debido al costo de Intellij. Con la adquisición de G2One por Spring Source, una de las expectativas es más soporte para Groovy y Grails en Eclipse. Esto será necesario para una mayor adopción.

Usar Grails para un nuevo proyecto es maravilloso. Gran parte del equipaje Enterprise Java ya no es necesario. Me imagino que intentar portar algo sería difícil porque hasta que no sepas dónde están las fortalezas y debilidades de un marco, es difícil utilizarlo de manera eficiente. Se promete que el soporte de JSP será más fácil en Grails 1.1, no sé si es una buena idea usar una versión beta mientras tratas de asimilar un nuevo marco. Las pruebas también han pasado por una revisión importante para la nueva versión. Si el tiempo lo permite, puede considerar esperar ya que la versión 1.1 debería ser muy pronto.

Si tienes la oportunidad de probar Grails en un IDE diferente al comenzar un proyecto desde cero, creo que lo verás bajo una luz diferente.

Estamos utilizando Grails + en la capa web + java con hibernación y la primavera en la capa de servicio. Son las tres capas clásicas (web, lógica, datos) donde la web es gruesa y la lógica se implementa en java. Como es habitual en java, usamos objetos de frijoles que representan los datos entre diferentes capas.

Funciona bastante bien y fue la mejor solución para nuestro caso ya que los objetos Bean ya estaban allí, así como la estructura de la base de datos. Desde nuestra experiencia, creo que Grails tiene un gran valor como capa de presentación web, pero me quedaría con Java para escribir las reglas de negocio y para persistir los datos de la aplicación, como Grails "es" Java, toda la integración Grails-Java es bonita sencillo.

Usamos eclipse para desarrollar la aplicación Grails y su pobre integración, como dijeron las personas aquí. Pero, como sugerencia de otro desarrollador, ejecutamos la aplicación grails desde la línea de comandos y solo usamos eclipse para guardar los archivos fuente, y funciona bastante bien, ya que la aplicación se actualiza sobre la marcha.

Todavía no me siento cómodo para usar griales en otros lugares que no sean en la capa de presentación.

Estoy totalmente de acuerdo con los sentimientos de los carteles originales.

Somos una tienda Java + Spring y aprovechamos la oportunidad para probar Grails. Primero creamos una aplicación de prueba muy pequeña que resultó ser bastante simple de hacer y funcionó bastante bien. Los principales problemas que tuvimos aquí se debieron a nuestra falta de conocimiento con Groovy y Grails.

Después de este éxito (impulso de confianza), decidimos intentar un proyecto un poco más grande. Esta ha sido una experiencia mucho más dolorosa. Como lo mencionaron otros, hemos descubierto todo tipo de errores y problemas que no fueron inmediatamente aparentes en la superficie. Los ciclos de reinicio de la aplicación son extremadamente dolorosos y, a menos que tenga una cobertura de prueba realmente buena, es una pesadilla hacer cualquier tipo de refactorización.

¡Realmente frustrante es tener un código fallido sin un solo mensaje de error! Simplemente no funciona y no sabes por qué?

Me gusta la facilidad de uso de los complementos para JMS, Quartz y Remoting, por nombrar algunos. Elimina una gran cantidad de tedioso XML.

Casi me gusta GORM por su simplicidad aunque hemos tenido varios problemas también.

No me gusta la naturaleza vagamente mecanografiada de Groovy y el hecho de que tienes que ejecutar tu aplicación solo para poder detectar un montón de errores, me recuerda demasiado a PHP o a Rails.

Al final del día nos preguntamos si es posible escribir una pieza compleja de software manejable usando Grails ...

Tenemos una aplicación de Grails a punto de entrar en producción ... así que ya veremos.

Grails puede ser grande para su tipo de aplicación (en base a los numerosos archivos que creó en la primera inicialización y los recursos que necesita). Si estás buscando algo simple, Grails podría no ser lo que estás buscando. Si estás buscando algo simple y funciona, hasta ahora creo que django puede hacer bien tu trabajo. Eche un vistazo a qué tan simple (cuántos archivos requiere) para crear aplicaciones CRUD desde su tutorial . Desde aquí, sus aplicaciones pueden (relativamente) ser fáciles de escalar a medida que crecen sus necesidades y requisitos.

No estoy seguro de que alguna vez puedan hacer que Grails sea correcto, ya sabes. Y por derecho me refiero a abordar todos los detalles (pequeños y grandes) que al final lo hacen sentir frágil y frágil. Ni siquiera estoy seguro de que haya un verdadero equipo de desarrollo (es decir, más de 2 personas) detrás de esto.

Cada vez que repito una característica de mis proyectos de Grails, tratando de mejorar algo, es el mismo flujo de trabajo: todo se desmorona, luego hay un centenar de ciclos de prueba de ''google'', luego descubres la razón por la que no puedes hacer lo que quieres y haces otra cosa.

Al final, estás frustrado porque ni siquiera quieres tocar nada que se ejecute. ¡Y las cosas que no funcionan bien, las dejas caer!

Estoy considerando cambiar a Rails a través de JRuby. Eso puede ser lo mejor de ambos mundos: un marco web capaz con una comunidad activa y grande, un equipo dedicado de desarrolladores, una plataforma que no se basa en marcos cuestionables y complejos como Spring o Hibernate, un ciclo de lanzamiento rápido y ambicioso. Y JRuby porque francamente, tantos elementos de Java en mi mochila, no puedo descartarlos.

Recién comencé a usar Grails en un nuevo proyecto ... no tener que escribir CUALQUIER archivo xml y aun así tener el poder de Spring e Hibernate es realmente increíble.

Sin embargo, uso IntellijIDEA para el IDE, descubrí Grails a través del IDE (aunque podría ser parcial, detesto el eclipse).

Si tu experiencia es en Java como dices. Deberías echarle un vistazo a playframework.org , es un marco web inspirado en Ruby on Rails con un ciclo de desarrollo muy corto, solo guarda tu archivo fuente Java y actualiza tu navegador web. Y si quiere probar otro idioma, Play Framework tiene un módulo que le permite usar Scala en su lugar.

Me gusta Play Framework ya que es fácil de entender y tiene un buen rendimiento. También puede usar JPA e Hibernate para la capa ORM si lo desea.

Tengo mucha más experiencia con Ruby on Rails que con cualquier cosa en el mundo de Java, así que vengo desde una perspectiva diferente. En general, Grails es mucho más áspero que Rails, en parte debido a su inmadurez, y en parte porque se basa en dos marcos increíblemente complejos bajo cubierta (Spring e Hibernate). Rails también tiene una comunidad mucho más grande.

Pero, Groovy como lenguaje ha hecho grandes avances, y es un placer trabajar con él. Gracias a las mejoras realizadas en Groovy 1.6, Grails es bastante más ágil que JRuby on Rails, y obtienes un soporte XML increíblemente bueno a través de GPath. Hay un montón de buenas características que obtienes al estar en la JVM (como la concurrencia y toneladas de código seguro), pero sin tener que preocuparte por Java (un lenguaje que no me gusta demasiado), así que estoy teniendo un verdadero Es difícil convencerme de usar algo en MRI.

Python parece tentador, debo admitirlo.

En cuanto a sus problemas de Eclipse, no puedo ayudar. Uso Vim y Emacs, principalmente porque no soporto el uso de IDEs. Sin embargo, para los lenguajes dinámicos como Groovy, Ruby y Python, no creo que los IDE realmente presenten ningún beneficio real, ya que no existe realmente ningún lugar para la generación de código o la necesidad de compilar. Tal vez intente trabajar sin IDE por un tiempo y ver si las cosas son más suaves?

Entonces, sí, creo que Grails lo vale. Han hecho un gran trabajo para hacer que las cosas funcionen tan rápido como lo han hecho, y los equipos de Grails y Groovy son realmente muy dedicados.

Totalmente. Hay tantos frameworks Java que la barra se establece bastante alta para los recién llegados, y es un testimonio de Grails que fue capaz de ascender en un espacio tan concurrido.

Todavía tiene algunos bordes que son nítidos, pero eso es solo una cuestión de tiempo antes de que estén enmarañados, el proyecto subyacente MUY vale la pena.

Valdrá la pena cuando terminen el plugin de eclipse. Cuanto antes, mejor lo digo. Tratar de venderle groovy a mi jefe no va a ser sencillo hasta que eso suceda.