Grandes aplicaciones con Groovy y Grails

El que sea necesario responder a esta pregunta significa que todavía existe una imagen bastante distorsionada de Grails. Así que antes de responderla, será necesario saber primero qué es Grails y cómo está hecho, y averiguar por qué es tan común está pregunta.

Grails es un framework de desarrollo para aplicaciones Web creado en Java y Groovy en 2005. Pero también es una herramienta de construcción de proyectos y testing a la vez, que permite, además, añadir plugins desarrollador por terceros. Tiene la peculiaridad de que abarca las tres capas del desarrollo web: acceso a base de datos, capa de negocio y vista. Y para conseguir todo esto en un solo producto, Grails se basa en otros (muchos) frameworks opensource conocidos: principalmente Spring Hibernate.

La principal característica y que más llama la atención de Grails es que esta diseñado para que programemos las aplicación en Groovy, un lenguaje dinámico con la misma sintaxis que Java, pero que añade muchísimas nuevas funcionalidades, permitiendo programar más con menos código.

Los orígenes

Sin embargo, Grails tiene fama de ser ideal para desarrollar pequeñas aplicaciones, pero para abordar una gran aplicación es mejor usar el stack de Java común hoy en día: Spring + Struts2 + Hibernate. Entonces me pregunto ¿y cuál es la diferencia, si Grails usa Spring + SpringMVC + Hibernate? Y es ahí cuando encontramos la semilla que siembra el temor en todos los arquitectos que se dedican a evaluar herramientas, antes de que los equipos de sus empresas empiecen a usarlas.

Estos arquitectos son los que, hace 10 años, evaluaron los Ejbs, los adoptaron y después se arrepintieron. Los mismos que, con mucha mas cautela, probaron y aceptaron Struts1 hace 8 años, y mejoraron su productividad, tanto que muchos equipos lo siguen usando hoy en día en sus proyectos. Los mismos que aceptaron sabiamente que Spring y Hibernate eran grandes herramientas, y las han convertido en un standard de facto para cualquier desarrollo actual. Y los mismos que tuvieron que descubrir como Struts1 fue una buena idea en su momento, pero que ahora se ha quedado completamente obsoleta, y tienen cada vez mas frameworks a elegir entre Struts2, JSF, SpringMVC, Wicket, Tapestry, Stripes… O entre Hibernate, iBatis, JPA, JDO…

Todos estos arquitectos llevan mucho tiempo, muchos años, probando nuevas herramientas, adoptándolas y desechándolas. Siempre aparece algo mejor, que se define a si mismo como la solución definitiva a todos los problemas. Pero después de tanto tiempo, no hay tanta confianza en las nuevas herramientas. ¿Y por qué? porque siempre requieren tiempo, una curva de aprendizaje. Y son fuentes de nuevos problemas, los problemas propios de la nueva herramienta y de integración con otras. Hasta el punto de que algunas empresas incluso han creado sus propios framework MVC y de persistencia.

Entonces estos arquitectos evalúan Grails, empiezan a programar controladores, prueban la persistencia, usan las vistas y dicen “¡qué fácil!”. Pero descubren que esto es posible porque programan con Groovy, y que Groovy es dinámico. Un lenguaje que resuelve las llamadas a métodos y evalúa las expresiones en tiempo de ejecución, no de compilación. Que no tiene un verdadero control de tipos, que es difícil refactorizar y depurar. Y empiezan a sospechar, claro. Pero cuando descubren que, usando incorrectamente el lenguaje, Groovy puede llegar a ser hasta 60 veces más lento que Java, es cuando Grails se desecha como opción directamente: ¿pero cómo voy a instalar en producción una aplicación que funciona hasta 60 veces más lento que la misma aplicación en Java?

La verdad sobre la velocidad de Groovy

Mi primera respuesta sería “no me importa que la aplicación sea más lenta, si puedo desarrollarla en menos de la mitad de tiempo o con una persona menos en el equipo“. Y es que en el ciclo de vida de desarrollo de un proyecto, tiene mucho más coste una persona más desarrollando, que poner un nuevo nodo en el cluster, ampliar la memoria RAM del hosting, o contratar una segunda máquina para el servidor.

Pero es que esto es falso. Spring, Sitemesh, Hibernate… todas las librerías que usa Grails están creadas 100% con Java. Y casi todo el código propio de Grails también. Veámoslo con números. Quitando las clases de tests, y sin tener en cuenta en qué están desarrolladas las partes más importantes (qué podríamos, y me consta que están en Java), este es el recuento de clases en función del lenguaje en el que están programadas (datos reales obtenidos sobre Grails 1.3.4)

Bauer.avilches:~/Work/Apps/grails-1.3.4/src2$ find . -name *.java|wc -l
    562
Bauer.avilches:~/Work/Apps/grails-1.3.4/src2$ find . -name *.groovy|wc -l
    155

Es decir, solo el 22% del código fuente de Grails está desarrollado en Groovy, el resto es Java auténtico 100%.

Entonces es cuando pensamos “ya, pero ¿y nuestro propio código, acaso no programamos las vistas, los servicios y los controladores en Groovy?“. Si, pero es que esa parte del código es mínima, si lo comparamos con todo el código que se ejecuta y el tiempo que se invierte en resolver una petición. Existe una gran cantidad de agentes intermedios involucrados que consumen mucho más tiempo, como el envío de información a través de la red, tanto la petición http como su respuesta, o el acceso a base de datos u otros servicios externos, desde el acceso a ficheros en disco a servicios web/rest. Y es ahí donde debemos preocuparnos por el rendimiento, no por la velocidad del lenguaje. Si nos preocupa el rendimiento, hay tareas muy concretas que se ha demostrado que funcionan, además de una buena optimización en la base de datos, cachear elementos estáticos, reducir o comprimir los recursos, aumentar el número de hilos, dividir la carga, etc.

Velocidad de ejecución vs. velocidad de desarrollo

Lo único en lo que no debemos escatimar es en la claridad en el lenguaje utilizado. Una mayor claridad significa menor cantidad código, pero mejor escrito. Significa que un nuevo programador se puede incorporar al equipo con el proyecto empezado, entender el código y empezar a trabajar rápidamente. Cada hora que un programador dedica a ponerse al día para entender cómo funciona un proyecto es dinero. Esta claridad, esta reducción de código con mayor funcionalidad, no lo conseguimos solo con Groovy, sino que ya lo llevamos haciendo mucho tiempo con Java.

Porque programamos en Java, ¿verdad? no programamos en C o en ensamblador, cuya velocidad de ejecución es varios ordenes de magnitud superior. No, lo hacemos en Java porque nos ha permitido hacer buenos diseños, usar patrones, nos permite programar de una manera clara, nuestra productividad mejora y somos más rápidos y mejores programando. Un lenguaje de alto nivel es más cercano al humano que a la máquina,es una abstracción que encapsula funcionalidades que alejan a los programadores del hardware. Cada nivel que sube un lenguaje, cada nivel que se aleja de la máquina, se añade más y más código intermedio por detrás. Instrucciones, rutinas, procesos, funciones, librerías, intérpretes, máquinas virtuales, clases, objetos, apis, frameworks. Java es un gran lenguaje de alto nivel, y Groovy lo es más todavía.

Resumiendo, preguntas y respuestas

  • ¿es más lento Groovy que Java? sí, pero solo en cosas muy puntuales.
  • entonces, ¿son verdad todos esos tests que dicen que Groovy es 60 veces más lento que Java? No del todo. Existen muchos benchmark publicados en internet comparando la velocidad entre Groovy y Java, con conclusiones como que Groovy era hasta 60 veces más lento que Java en un código equivalente. En la siguiente presentación que hizo Jochen Theodorou, uno de los líderes de Groovy, en la GR8, nos explica la realidad sobre los microbenchmarks, y como el mismo test, bien y mal diseñado, puede dar resultados muy dispares. Siempre hay que comparar el código más óptimo equivalente entre dos lenguajes, una línea situada dentro o fuera de un bucle puede hacer que una prueba tarde un orden de magnitud más.
  • ¿penaliza la velocidad de respuesta de una petición http? técnicamente, si, pero es despreciable.
  • ¿es siempre Groovy más lento que Java? no, es posible hacer optimizaciones muy simples en nuestro código para incrementar la velocidad.
  • Groovy es un lenguaje dinámico, por lo que hay muchos errores que deberían aparecer en tiempo de compilación y que no salen. Estos errores aparecen después, en tiempo de ejecución, a veces en producción ¿cómo lo evito? esto en realidad es un problema de metodología, no del lenguaje. Pero que sale a la luz cuando usamos lenguajes dinámicos. El verdadero problema es que no existen pruebas unitarias suficientes y hay poca cobertura de código. La solución es hacer más tests, lo cual tiene muchos más beneficios de lo que a simple vista parece. Más información aquí, es un artículo del 2006, pero que sigue vigente hoy en día.
  • ¿Está haciendo algo el equipo de Groovy para incrementar la velocidad? Si, son muy conscientes de ello y están trabajándolo.
  • Si uso Grails ¿estoy obligado a programar todo en Groovy? no, puedes programar en Java si te apetece, o si hay una parte crítica en tu sistema (complejos cálculos matemático, por ejemplo) que necesita el máximo rendimiento, pero tendrás que prescindir de la riqueza del lenguaje que añade Groovy a Java.
  • ¿tiene una curva de aprendizaje Groovy? si, pero si ya conoces Java, es muy pequeña.
  • ¿tiene una curva de aprendizaje Grails? si, pero si ya conoces Spring e Hibernate, es muy pequeña.
  • ¿puedo tener problemas con Grails? si, principalmente los mismos que tendrías al usar Spring e Hibernate. Y algunos nuevos que añade el simple hecho de usar una nueva plataforma, pero nada está exento de errores.
  • Entonces ¿puedo hacer una gran aplicación con Grails? Claro. Si la puedes hacer con Java con las mismas herramientas (Spring + Hibernate), también la puedes hacer con Grails, y además en menos tiempo, gracias a Groovy.
Photo of Alberto Vilches

Alberto Vilches es arquitecto de software y consultor pero, sobre todo, es programador. Lleva más de 12 años trabajando en el desarrollo de software y 10 con Java. Ha trabajado en banca electrónica para el BBVA y desarrollando con J2EE en IT Deusto. También ha desempeñado otros roles diferentes a la programación como instructor y consultor Weblogic para BEA Systems y analista de sistemas en Aena. Actualmente se encuentra en Paradigma Tecnológico. Cree en los lenguajes para la máquina virtual Java como medio para mejorar la productividad y la creatividad en la programación. Apuesta firmemente por el ecosistema Groovy y Grails como herramientas de desarrollo ágiles, impartiendo formación y seminarios, y asistiendo a conferencias especializadas.

Ver toda la actividad de Alberto Vilches

Recibe más artículos como este

Recibirás un email por cada nuevo artículo.. Acepto los términos legales

21 comentarios

  1. Jorge dice:

    Desde la experiencia de varios proyectos *grandes* puestos en producción con Grails, creo que los impactos en rendimiento son equivalentes a los de cualquier desarrollo java en el que haya trabajado antes, y las áreas de intervención muy parecidas:

    – Profiling de operaciones con DB / Tuning de cachés y lazy-loadings

    – Profiling de capa de presentación, y cacheo de fragmentos o de páginas en los casos en que aplique

    – Un poco de “conocer lo que hay debajo”, entender las implicaciones de las llamadas a un servicio transaccional, por ejemplo, y entender las implicaciones de que un código se ejecute asociado a una clase de dominio (por ejemplo) o en una clase de servicio transaccional.

    – Gestión eficiente de los GCs, tuning de la puesta en producción y resuesta a cargas altas de trabajo (equivalente totalmente a Java, con algunas peculiaridades menores con los permgem y cosas así)

    Pero es que siempre pasa lo mismo, el que hace un benchmark suele comparar un framework optimizado (el que mejor conoce) con un “hola mundo” sobredimensionado en el que se va a comparar… no hay que fiarse demasiado de esos análisis, salvo como aviso a navegantes: “No silver bullets” ;)

  2. Nacho dice:

    Buenas Vilches,

    Mi experiencia con Grails me ha generado una duda. El tema de convención sobre configuración en grails esta muy bien con spring e hibernate, pero para un proyecto grande muchas veces tienes la necesidad de bajar un nivel más abajo y, por ejemplo, configurar directamente parámetros de configuración de hibernate o crear un nuevo metodo de autenticación en sprint security. Este tipo de configuraciones me ha resultado mucho más complejo con grails ¿Que opinas?

  3. Excelente post, Alberto. Yo no lo hubiese dicho mejor.

  4. Dani Latorre dice:

    Buen post Alberto! Aunque lo de “grande” pueda significar cosas diferentes :)

    Nacho, spring security no lo sé, ese plugin lo he utilizado muy por encima. Pero para configurar hibernate puedes usar spring como siempre, no tiene ninguna complicación mayor a cualquier otro “stack” sobre spring+hibernate.

  5. Yo, particularmente, soy reacio a frameworks y a “capas de cebolla”, pues suelen meter en un paquete más funcionalidades de las que puedes necesitar, con el consiguiente incremento de consumo de recursos (memoria, tiempos de CPU, etc). Sin embargo, en desarrollos complejos y grandes, estas funcionalidades se ven aprovechadas, y es cuando se aprecian sus bondades. Groovy es la implementación de Ruby en Java, abstrayendo el lenguaje y añadiendo nuevos paradigmas, lo que hace un código más natural e intuitivo, amén de escribir menos código. Grails tiene la filosofía de Ruby on Rails, acelerando el desarrollo de aplicativos Web reaprovechando funcionalidades repetitivas. Aún no he tenido la ocasión de utilizar estas tecnologías, pero el concepto me convence, pues ya tengo algo de experiencia en Ruby y en Python. Creo que en desarrollos pequeños la potencia no se aprecia, pero en desarrollos grandes se gana en productividad y en desarrollos con menos errores.

  6. Jorge: estoy contigo 110%

    Nacho: con respecto a bajar de nivel, creo que en el caso de Hibernate creo que no hay mucho problema: es posible utilizar descriptores de *.hbm.xml, y tienes acceso tanta al session factory como al datasource, por lo que es casi transparente. En el caso de Acegi y SpringSecurity creo que es más un problema del propio plugin y como lo integra con Grails, que del propio Grails. De todas formas, Grails no está exento de nuevas dificultades. Para mí lo importante es que el equilibrio entre lo que me aporta y lo que tengo que luchar (ya sea curva de aprendizaje, problemas o bugs) sea a mi favor, y en el caso de Grails la experiencia nos dice que así lo es.

    Alvaro y Dani: muchas gracias, en el trabajo muchas veces tenemos que responder a esta pregunta, así que lo mejor es publicar un artículo como éste en internet y ver si la gente reacciona positivamente. Como ha sido el caso, veo que no vamos desencaminados :)

    Rafael: yo no veo realmente a Grails como una capa de cebolla. Quizá pudiera serlo, pero es bastante fácil acceder a Spring y a Hibernate que supuestamente esconden.

    La implementación de Ruby en Java es JRuby, Groovy es un lenguaje inspirado en Python, Ruby y otros muchos lenguajes, aunque te doy la razón en que Grails está completamente inspirado en RoR. Te animo a que lo pruebes, pero veo que ya debes de estar en ello. :)

  7. jneira dice:

    Ningun pero al tema de relativizar la importancia de la rapidez de ejecucion, creo que lo de “la optimizacion prematura es el origen de todo mal” todavia no esta muy asumido.

    Sin embargo en cuanto al tema de la complejidad creo que el contexto de la experiencia es importante para entender las conclusiones. Este contexto, corrigeme si me equivoco, es el de un equipo tecnico con bastante nivel general(mas de la media), con experiencia (sufrida) anterior en los frameworks j2ee utilizados por grails (sobre todo hibernate y spring) y que practica la tdd. En ese contexto las conclusiones son totalmente acertadas.

    A medida que el contexto se aleje del descrito los riesgos al adoptar grails aumentan: ¿recomendarias usar grails en un projecto grande en un equipo con un nivel medio, que no practica tdd y que no tiene experiencia previa en hibernate y spring?

    Y si que creo que es una capa de cebolla, mas o menos transparente (segun tus conocimientos del propio grails y de spring/hib) pero una capa mas que simplifica ocultando la complejidad subyacente y no eliminandola, con las ventajas e inconvenientes que supone. Y eso no estaria tan mal si nunca hubieras tenido el momento zen de ver un lenguaje o una libreria o una herramienta que cortan el nudo gordiano y realmente hacen la programacion mas sencilla, aunque sea replanteandose las cosas desde su misma raiz.

  8. Interesante reflexión, pero podemos verlo de la otra manera: ¿recomendarias usar spring+hibernate en un proyecto grande con gente de nivel medio, que no tiene experiencia previa en hibernate y sptring, y no practica TDD?

    Este caso es bastante peliagudo también, aunque me consta que es bastante mas popular. Yo creo que siempre, en todo proyecto, hay alguna o varias personas que al menos controlan la arquitectura: me cuesta creer que abordar un proyecto sin que ninguno de los integrantes conozca los frameworks a utilizar se realize en un tiempo normal y sin caer en ciertas malas practicas debido a la inexeperiencia o al aprender sobre la marcha.

    De todas formas, en este caso, el tipado fuerte y los errores de compilacion harán mas fácil la vida diaria, ya que “solo” tendrían que enfrentarse a los retos que le supone usar los nuevos framework que desconocen (principalmente Hibernate creo yo). Pero desde luego, la duración del proyecto será muy grande.

    Creo que, usando Grails, este equipo de nivel medio y sin experiencia, tendrían más problemas por el uso de un lenguaje dinámico (errores en tiempo de ejecución) que por el uso de spring/hibernate, que serían casi transparente. Aunque luego aparezcan los mismos problemas (LazyInitializationException, NonUniqueResultException).

    De todas formas, creo que abordar un gran proyecto sin que nadie del equipo tenga experiencia en la arquitectura puede ser un error, se use el framework que se use. No un error porque no se finalice, sino porque se tarde demasiado y no sea rentable. Para evitar esto solo hay dos soluciones: o meter a alguien en el equipo con experiencia, o iniciar primero un proyecto pequeño para poder adquirirla sin que se produzca una desviacion en el tiempo exagerada. Y después abordar uno grande.

  9. Grails está diseñado para que todas las capas vivan juntas, tal y como lo harías en una aplicación no-J2EE basada en Spring. Pero si deseas separar la presentación del negocio lo puedes hacer perfectamente. El proyecto que hemos desarrollado en Paradigma para http://ringio.com tiene 3 aplicaciones Grails que ofrecen una api privada con http y rest, que es lo más cómodo y rápido que hemos encontrado. No es una separación real entre la lógica de negocio y la presentación, pero debería valer igualmente.

  10. migue dice:

    Buen post Alberto, enhorabuena!

    Respecto a la separación de capas (adicional a la opción REST de Alberto), la integración entre las mismas se puede hacer mediante diferentes mecanismos como pueden ser web-services tradicionales (wsdl), HttpInvokers, etc

  11. Tienes razón Migue, la verdad es que Grails como tal no ofrece ningún sistema de integración, pero hay algunos plugins interesantes:

    – Por ejemplo, el plugin “remoting” http://www.grails.org/plugin/remoting permite exponer servicios como RMI, Hessian, Burlap y Spring’s HttpInvoker (Java serialisation over HTTP).

    – Para hacer un api rest has de programar simplemente un controlador, crear un objeto y serializarlo en la respuesta con un simple render x as JSON.

    – Y para servicios web existe un plugin para CXF: http://www.grails.org/plugin/cxf

  12. Aitor Alzola dice:

    Hola, la pregunta en mi opinión no es si se puede, que seguro que se puede, sino cuanto va a doler. Y se puede hacer igual para Groovy/Grails, que para Java/pongaAquiElFrameworkQueMasLeHaHechoSufrir.

    No sé si tengo experiencia en grandes aplicaciones (depende de lo que sea grande), pero casi seguro que si es demasiado grande es mejor intentar hacerla más pequeña, más modularizada… y esto va a ser siempre problemático independientemente del lenguaje/framework, sobre todo si tu equipo no tiene la experiencia suficiente.

    De todas maneras, si creo que G&G aportan una simplificación de las tareas más habituales, es decir, lo habitual es fácil y lo complicado posible, que aumenta la productividad de tu equipo, y en consecuencia, su felicidad.

    En resumen, creo que es igual de posible hacer aplicaciones (grandes o pequeñas), con Grails que con otros frameworks, pero con Grails lo harás un poco más rápido.

  13. iCesofT dice:

    Hola,

    Pregunta por desconocimiento: con Grails puedes separar realmente las capas de presentación y lógica de negocio en distintas máquinas/subredes fácilmente? En caso afirmativo, cómo sería la integración? Vía RMI? Opción para utilizar otros medios? Al utilizar Spring entiendo que sería fácil invocar servicios remotos ofrecidos desde otro servidor de aplicaciones.

    Un saludo.

  14. Jaime Carmona Loeches dice:

    Gran artículo Alberto.

  15. jneira dice:

    Bueno la diferencia seria como empezar a usar una casa con los cimientos y la estructura al aire, amueblarla tu y aprender como esta por debajo en el proceso o empezar a vivir en una ya decorada y amueblada y no saber nada (o no lo suficiente) de como esta hecho por debajo. Para empezar no esta mal y si va todo bien no hay problema, pero si las tuberias se atascan solo tienes dos opciones, empezar a desarmar la cosa a ciegas o pagar a un fontanero y ninguna de las dos opciones es muy atractiva.

    Y por eso no es cuestion de hibernate+spring *o* grails, sino hibernate+spring *y* grails encima. Parece mas prudente sufrir primero la parte baja de los stacktraces ellas solas, aprender de los errores y tener un conocimiento solido de la base y luego ir aumentandolas con grails.

    Ciertamente el dolor suele estar en hibernate (creo que esta claro que los orm son el vietnam de la ingenieria del software) y no en el propio grails pero otro problema es que hasta hace poco tienes que “comprar” el pack entero (hibernate-spring-sitemesh-grails) en plan monolito. Y es otra de las cosas que no me convencen del todo de grails , vale que por ahora (excepto lo de sitemesh que la verdad es un poco extraño) son los frameworks mas utilizados pero no tiene porque seguir siendo asi. Hace poco se ha dado un paso en el buen camino haciendo posible usar bases de datos no relacionales y supongo que en la medida que se empiece a ver que hibernate no es La Solucion (al menos tan generalizada como ahora) grails se adaptara haciendose mas modular en su infraestructura y menos dependediente de unas librerias concretas. Precisamente una de las cosas que me gustan de spring es su modularidad y que no se casa con ningun framework de mvc o de orm sino que puedes utilizar el que mas te convenga (o incluso ninguno).

    ¿¿Porque que pasa si mi contexto de negocio hace que se ajusten mejor play para la parte web, google guice para la injeccion de dependencia e ibatis para el orm?? Pues que me puedo ir olvidando de grails tal y como esta hecho ahora (o modificarlo muucho)

  16. Aitor Alzola dice:

    Efectivamente Grails viene empaquetado en un todo o nada, y por un lado es una desventaja clara si Hibernate no te convence (la verdad es que a mi no me gusta mucho), pero por otro lado que venga con todo puesto es una GRAN ventaja con respecto al stack vamos a decir artesano en el que tu eliges pero también tú eres el que le da pegamento a todo. En fin, cada aproximación tiene ventajas e inconvenientes… Igual para próximas versiones de Grails se consigue esa modularidad…

  17. Hola Aitor. Pues precisamente Gorm es la parte de Grails que están intentando separar, tanto para usarla en otros proyectos fuera de Grails, como para usar otro motor de persistencia en Grails, como Redis o iBatis

    Cómo usar GORM sin Grails: http://www.grails.org/GORM+-+StandAlone+Gorm

    Soporte de Gorm con Redis (NoSQL): http://blog.springsource.com/2010/09/07/announcing-gorm-for-redis/

    Soporte de Gorm con iBatis: http://www.grails.org/plugin/ibatis

  18. Dani Latorre dice:

    Grrr… Me he estado perdiendo esta conversación tan interesante! Bueno, más vale tarde que nunca, aportaré mi humilde punto de vista :)

    Efectivamente GORM es lo que se ha ido intentando separar de Grails, lo que no quita a que Grails esté “opinando fuertemente” que debas usar GORM/Hibernate, casi toda su documentación por un lado, y la generación automática de código por otro, cuenta con ello(al menos por defecto).

    Pero como framework opinado que es, no te apunta con una pistola para obligarte a que utilices las herramientas que te propone. Tienes la alternativa de usar esos otros motores de persistencia en forma de plugins, como tirando de JDBC/JdbcTemplate/GSQL directamente o con otros motores de persistencia escribiendo tú el código pegamento para integrarlo(esfuerzo que Spring seguramente suavizará :)).

    Yo creo que lo único de lo que es imposible despegar es Spring y Groovy, aunque pudiendo utilizar controllers de spring mvc y freemarker para las vistas, se podría minimizar muchísimo incluso el uso de Groovy(aunque a mi me parezca un poco absurdo llegar a ese punto :D)

    Aunque eso sí Javier, si en la parte web quieres usar play!(framework al que le debo un vistazo serio hace meses), no veo sentido plantearse usar grails, igual que tampoco lo veo en usar guice y spring a la vez para la inyección de dependencias.

  19. iCesofT dice:

    En un aplicación “grande”, la lógica de negocio “suele” estar implementada en una herramienta tipo BPM, de forma que, desde ésta, se invoquen los servicios SOA ofrecidos por el resto de la compañía (normalmente servicios basados en WSDL o utilizando algún ESB para la integración).

    Pese a que puede que me crucifiquéis por ello, creo que para desarrollos “grandes” en las compañías actuales, veo Grails + Groovy únicamente en la capa de presentación. Defino desarrollos “grandes” como desarrollos en los que debes integrarte con múltiples sistemas heterogéneos.

  20. iCesofT, estoy contigo totalmente: si la capa de negocio va a estar en servicios externos, Grails está más orientado a la capa de presentación (aunque eso no quita que se puedan desarrollar servicios web con Grails).

    Sin embargo, a una aplicación desarrollada con el stack tradicional de Spring+Struts+Hibernate le pasaría lo mismo: se quedaría en la vista y usaría los servicios como un cliente más.

  21. jneira dice:

    Ole, no sabia lo del plugin de ibatis, +1 para grails por ello. Me corrijo en lo de la critica por la dependencia tan fuerte de grails sobre hibernate (tecnicamente no lo es tanto como pensaba aunque en la practica siga siendo el estandar como bien dice dani)

    Que spring no se pueda separar no me preocupa tanto, demas siendo que grails es de la compañia que creo spring no parece que vaya a haber muchos esfuerzos en ese sentido :-P. Efectivamente no tiene sentido usarlos a la vez me referia a sustituir spring con guice aunque ya digo que tampoco me preocuparia.

    Por otro lado creo que he leido que grails va a empezar a usar osgi para la gestion de la modularidad (no se si de los plugins secundarios y/o del mismo nucleo de grails) e indpenedientemente si osgi es una buena opcion o no creo que la intencion es la correcta.

    En cuanto a la parte de la presentacion y al hilo del comentario de dani, creo que mi desconocimiento de play igual me ha hecho demasiado atrevido ¿son alternativos play y grails?¿no podria ser usado en la parte de presentacion en lugar de sitemesh?

Escribe un comentario