www.javahispano.org: Tu lenguaje, tu comunidad

Aclaro que soy un novato en esto de los frameworks, pero he probado grails y analizado un poquito de openXava, y me parece que este tipo de frameworks pueden darnos muchísimo provecho para una aplicación de este tamaño.

Un compañero de trabajo se opone al uso de estos framework, ya que argumenta que solamente son útiles para aplicaciones pequeñas a medianas (no especificamos cual es el criterio para aplicación "grande" o "pequeña") y que no le gustan por que generan mucho código basura.

Si alguien tiene conocimiento de algún framework que se más apropiado para este tipo de aplicaciones (además de Struts), ó si alguien sabe de alguna aplicación con similares características desarrollada en Grails o con algún otro framework se los agradecía muchísimo.

"generan mucho código basura"

Código basura es el que vais a tener que escribir a manubrio sino utilizais ningún framework. Además que ni grails, ni openXava, ni struts, ni ... son generadores de código, argumento que más parece una excusa para no tener que aprender ningún framework..., cual es la alternativa que propone?, servlets+jsp a pelo?, o quizas mejor directamente tirar de java.net y escribirse el soporte para HTTP a mano también que las implementaciones de servlets tienen mucho código basura

Sobre el tamaño de la aplicación, creo que primero conviene distinguir a que nos referimos con "aplicación grande":

- Aplicación grande en cuanto que ofrece muchas caracteristicas, es decir muchas lineas de código.

- Aplicación que va a recibir mucha carga de trabajo, entonces estamos hablando de escalabilidad.

Para el primer punto, manejar una base de código grande en una app web sin usar un framework MVC es meterse en un lio y de los gordos. Estos frameworks no sólo te ayudan dando ciertas funcionalidades sino que te proporcionan un marco para organizar tu proyecto de forma adecuada.

Para el segundo punto, la escalabilidad, pues esto en realidad depende muy poco del framework y mucho de que tu aplicación tenga en cuenta la escalabilidad desde un principio, por ejemplo no almacenando muchos datos en la sesión, teniendo mucho cuidado con lo que se hace con la base de datos (usar un pool, transacciones cuantas menos mejor, definir bien los indices...), vamos que en definitiva la escalabilidad depende mucho más de otros factores que del framework web que uses. 

En resumen, usar un framework y no reinventeis la rueda, hacer pruebas con varios y elegir con el que os sintais más comodos, grails personalmente me parece una opción estupenda, y si no os va groovy pues podeis probar con stripes o struts2. (personalmente cada día valoro más la simplicidad, y stripes me parece estupendo por lo simple que es).

Pero vamos hacer un app web hoy en día sin usar algún framework MVC es como usar System.out para escribir el log en lugar de usar log4j...

Mas que una cuestión de "tamaño", para mi la elección de frameworks es una cuestión "orientación". Toooooodos los frameworks, te cuenten las trolas que te cuenten, están orientados a cubrir un tipo de funcionalidad y darte hecho o facilitarte un 80% del trabajo de ese tipo (por decir un % alto) y hay un 10% que se complica. La cuestión es que si tu aplicación no se ajusta a eso, a lo mejor ocurre que te dan hecho a ti el 10% y el 90% te lo complican...

Por ejemplo, si tu aplicación está muy orientada a mantenimientos estilo gestion, OpenXava te puede dar el 80% hecho, pero si en realidad solo tienes un mantenimiento y toodo el resto de tu aplicación es "interfaz web", pues mucho mucho no te ayudará si lo usas para todo. Y al reves.

Así que lo que hay que mirar es que los puntos fuertes del framework a usar coincidan con lo que necesitas y vayas a aprovechar al máximo. 

Y en cuanto a escalabilidad, pues como dice remoh es cuestion de configurarlo adecuadamente, pero tampoco hay que mirarlo por "numero de personas". 200 personas trabajando todo el tiempo te pueden dar muchos mas problemas que 20.000 que solo acceden de pascuas a ramos, excepto ese día que se conectan todas de golpe y tienes que aguantar el pico de carga... pero eso es algo que hay que estudiar, el numero de personas en si mismo no dice mucho.

Suerte

Como dice greeneyed hay frameworks que cubren necesidades muy especificas, esas las cubren bien pero te pueden complicar el resto.

Si tu tipo de aplicación es más orientada a "componentes", es decir una app de gestión metida en una web, entonces frameworks con esta orientación te pueden ayudar más: JSF, Wicket, tapestry o el mismo GWT si quieres una aplicación totalmente "ajaxificada" (toma palabro). Algún ejemplo:

- Artifactory esta construido con Wicket

- Aqui puedes ver algunas aplicaciones construidas con gwt

Para que te hagas una idea del tipo de aplicaciones a las van dirigidas estos frameworks. Nosotros particularmente usamos GWT+SmartGWT para aplicaciones de este tipo. (Se consiguen buenos resultados, a la vista esta el showcase, pero cuesta empezar si no tienes experiencia previa en gwt no te voy a engañar).

Luego si tu aplicación es más "web" (digamos un site tipo javahispano por ejemplo): entonces frameworks MVC puede ser más adecuados: struts2, stripes, spring mvc, grails entraría en este capitulo también (jobsket es un ejemplo de app realizada con grails)

"La propuesta de mi compañero es el Struts+JSF."

O lo uno o lo otro, los dos juntos no le veo mucho sentido. de todos modos Struts esta desfasadillo, mucho mejor cualquiera de las opciones MVC que te comentaba antes. Y JSF, pues para gustos colores, a mi no me gusta nada, me quedaría antes con wicket o gwt. de todos modos esta va también en gustos, hay gente que trabaja con jsf y no le va mal. (iceFaces parace lo más recomendable como implementación de jsf, pero aqui hablo más de oidas que otra cosa)

Esta aplicación cae en la segunda clasificación de escalabilidad que menciona Greeneyed, actualmente se realizan los registros de aspirantes a la universidad por medio de un formulario en línea. Así como el resultado del examen de admisión. En total al año son como 6 ocasiones en las que la aplicación se encuentra en su pico máximo.

Creo que es un punto muy bueno el tomar las cualidades que puede ofrecer en para esta aplicación. Le voy a dar una mayor importancia a este punto.

Mi compañero de hecho ya detallo un poco más las herramientas que sugiere para esta aplicación. JSF para la vista, EJB para la capa de negocio y JPA para datos, todos comunicados con Sprint.

Remoh, tus sugerencias me son de mucha ayuda. Gracias.

Si la cuestión es que tienes picos máximos 6 veces al año, una idea sería escoger algo ligero y adaptable, aunque el coste sea que no tenga todas las mega-chuladas que ayuden en el momento de desarrollo, ya que desarrollarlo se desarrolla una vez, mantener la aplicación suele ser más tiempo.

Nosotros en la universidad, por ejemplo, tenemos el proceso de selectividad que es el stress máximo de una única aplicación (no en global ni distribuido) donde 2 veces al año, hay una hora, una hora y media en que "hay prisa". Otras aplicaciones las han sustituido por versiones más modernas con "frameworks más molones" y sistemas más complejos en cuanto a seguridad, flexibilidad etc. empeorando el rendimiento lo que no está escrito, pero ésta aplicación en concreto no se atreve, afortunadamente, y continua con un framework MVC "directo" con pocas pijadas pero que puede con la carga sin apenas traumas.

No lo digo por recomendar un framework en especial, que no me gusta y no es el caso, si no por poner un ejemplo donde no hay que fijarse tanto en "todo lo que le ofrece al desarrollador" si no en otros aspectos como que sea realmente "ligero y directo" por cuestiones de rendimiento.

Coincidiría con remoh en cuanto que Struts 1 está algo pasadillo ya, y los propios creadores de Struts consideraron que se había vuelto complejo y pesado, y JSF personalmente tampoco me gusta (no soy de la vision orientada a componentes ni a un stack 100% exclusivo Java). Si estamos hablando de una aplicación abierta a todo el mundo, (y si es universidad debería ser además accesible) quizá tampoco sería bueno abusar mucho de JavaScript/AJAX, por lo que tampoco recomendaría GWT o cargar mucho las tintas en el JavaScript.

Suena un poco extraño, pero es más fácil ir descartando que escoger entre todos los que hay, ya que es más fácil detectar lo que claramente no funcionaría o no te gusta de lo que "bueno, podría servir".

Suerte

Muy de acuerdo con todas las sugerencias de greeneyed, si la aplicación va a estar públicada de cara a que la gente entre desde sus casas y demás, lo mejor es no abusar mucho del JS y tener cuestiones de accesibilidad en cuenta. Para este tipo de escenarios GWT o IceFaces en mi opinión quedarían descartados. (y eso que soy el taliban de gwt de javahispano xddd), mejor algo más simple pero que le funcione a todo el mundo sin problema. 

Yo personalmente teniendo en cuenta el escenario creo que me decantaría por grails como primera opción, me encanta groovy!.

En caso de no gustaros groovy, tiraria por stripes+spring+jpa/hibernate. (ejb si usais spring no le veo mucho sentido y os ata a un app server con soporte de ejb).

Y si no queda más remedio que usar JSF, yo le echaría un vistazo a jboss seam, que alivia muchos de los problemas de JSF.

Aunque la elección de frameworks va un poco en gustos, lo más importante es que luego os empapeis bien del framework que termineis seleccionando, con cualquier de ellos estoy seguro que os puede quedar un buen trabajo si luego se usa adecuadamente.

xD que buena discusion

teniendo en cuenta lo comentado y retomando la pregunta original, mi repuesta es SI. Grails es un framework que te serviria muy bien para desarrollar la aplicacion que necesitas. Mis razones son:

1) Grails esta construido sobre lo mejor de Java: Spring + Spring MVC + Hibernate + SiteMesh. Estos frameworks han demostrado ser los mas robustas y tienen muuuchos años funcionando en proyectos muuucho mas grandes del que piensas hacer

2) Con Grails solo te toca aprender un solo framework que hace de todo

3) Groovy es 100% igual a Java si lo quieres. Es decir que si no quieres aprender Groovy programa en java pero los archivos con extension .groovy en vez de .java. Lo mas seguro es sin darte cuenta con el tiempo comienzas a usar cosas propias de groovy

4) un buen servidor es importante, Tomcat puede soportar esa carga de usuarios siempre y cuando este bien configurado, por ejempo que utilice el conector AJP o HTTP Nio que soportan la conexion de miles de usuarios simultaneamente sin que explote

5) Y como plan de contingencia podrias tener otros Servidores con Tomcat listos para trabajar y los clusterizar utilizando Terracota sin tener que cambiar nada en tu aplicacion.

Hola de nuevo,

BUENROLLOMODE ON

En mi opinión las que mencionas, Marioko, no son razones muy apropiadas para escoger un framework, como mínimo en este caso.

1) Escoger un framework por "el renombre" es un sinsentido que uno sólo debería hacer si no tiene conocimientos y no tiene forma de probar por si mismo. Sin tener nada en contra del framework en si o de los componentes que usa, fíjate que en ningún momento dices "y esto precisamente se adapta como un guante a lo que necesitas". Es todo genérico. Y que la gente haga proyectos muuucho más grandes con eso puede querer decir que a ti te sobra.

2) Eso puede ser bueno o malo, ya que te casas con ese framework al 100%. E igualmente, es una ventaja para el desarrollador y en este caso ya hemos "acordado" que lo que ha de primar son otros factores.

3) Groovy no es Java. Si lo vas a usar como Java, usa Java que te irá mejor. Si usas Groovy, que sea por una buena razón y para sacarle partido.

4) Velocidad vs Tocino ;). ¿Que tendrá que ver el contenedor de servlets con el framework? La mayoría de frameworks son independientes de contenedor, si no, los tiras a la basura. Además, personalmente no me gusta el Tomcat, pero ese es otro tema.

5) Velocidad vs Tocino II ;). Este tema, aunque interesante, es igualmente independiente del framework y es algo que uno ha de mirar si un sólo servidor no le va a dar, o para tolerancia a fallos. Pero empezar por ahí para mí entra dentro de "premature optimization", que es según algunos "the root of all evil" ;).

Y con todo eso no quiero decir que Grails no serviría, simplemente que escogerlo por las razones mencionadas sería, en mi opinión, un error.

BUENROLLOMODE OFF

PD: Lo de buenrollomode lo digo por que no quiero que suene a crítica ni nada, sería mejor hablarlo en un bar riéndonos sobre una cocacola pero como no se puede pues lo hacemos por aquí que es más impersonal.

jeje no te preocupes greeneyed, yo todos los comentarios los paso por mi BUENROLLO-FILTER! xD

1) pues cuando digo que Grails esta construido sobre lo mejor de Java, pues no lo digo simplemente por el renombre, de hecho yo practicamente utilizo las mismas tecnologias que usa grails por debajo y puedo asegurar que son muy buenas y que pueden facilmente soportar el proyecto que piensan desarrollar. Ademas siempre cabe la posibilidad de que el proyecto crezca muucho mas y tener un framework bueno a tus espaldas te ayudara a soportar lo que venga.-

 2) Para alguien que aun no conoce ningun framework o esta indeciso entre el monton que hay lo mejor es casarce con uno, al menos al prinicipio (no me refiero al prinicipio del proyecto sino de su carrera con frameworks java, en otros proyectos puede cambiar)

3) jeje yose que cuando digo Groovy es Java suena a publicidad, pero si usas Grails te tocara usar Groovy y si no quieres complicarte con el lenguaje al principio puedes usar la sintaxis de Java y listo, igual el compilador de groovy todo lo que tenga sintaxis java genera el mismo bytecode que el javac. Ademas se podrian utilizar clases java pura para parte criticas de la app.

4) obviamente el contenedor de servlets no importa mucho para elegir un framework y para empezar el proyecto pues tampoco, pero si se debe tener en cuenta al momento de poner en produccion el proyecto. Si a ti no te gusta Tomcat no sera por el gato amarillo y feo, seguro es porque crees que X o Y caracteristica funciona mejor y es mas estable en A o B servidor. Yo por ejemplo uso Jetty en produccion cuando hago proyectos grandes. La razon es que las continuations de Jetty son muy muy potentes para gestionar miles de conexiones y ademas el ajax push es mas estable y consume menos memoria. 

saludos 

Repito que no digo que Grails no sea buena elección pero..

1) Si estabas pensando en algo más que el renombre, no lo has dicho, así que a efectos prácticos es como si no lo hubieras hecho ;). Y de todas formas, aunque yo tambien uso muchas de las librerías que usa por debajo, discrepo en que todas sean necesarias y que sirvan perfectamente para la aplicación en cuestión. Hibernate, por ejemplo, (GORM) seguramente no se adapte a no ser que la aplicación tenga un modelo de datos y consultas que sea "por objetos". Spring y SiteMesh, por otro lado, son herramientas para dar ventajas en desarrollo, así que aunque pueden servir, tampoco las veo como imprescindibles y segun el principio de la navaja de Ocam...

2) De nuevo volvemos a ventajas para el desarrollador cuando lo importante en este caso es primero el rendimiento.

3) Pero es que eso de que puedes usar los dos indistintamente es "falso", o estas haciendo el tonto de mala manera. Si usas Groovy es por las ventajas que trae, si lo usas como Java no las aprovechas y "para ese viaje no hacen falta esas alforjas".

4) No digo que elegir un buen contenedor no sea necesario, pero lo que digo es que es ortogonal a escoger un framework. Es decir, no tiene "nada que ver".

jeje pues solo decir que el tema de usar Groovy con sintaxis java es solo para resolver el posible problema de: "Hey pero si usamos grails entonces nos toca aprender ootro lenguage de programacion, y para eso no hay tiempo ni aguanta... ". Si usan grails y groovy pues mejor

en lo demas estoy deacuerdo contigo

Pero es que es como decir... "bueno voy a usar la BDD Oracle por que tiene PLSQL, pero como no tengo tiempo de aprenderlo, usaré SQL a pelo". ¿¡!?

Si no tienes tiempo de aprender Groovy, no uses Grails, punto. Todo lo bueno que te da, te lo da por que es Groovy y no Java, si no vas a aprovechar nada de eso... ya lo usarás cuando tengas tiempo. 

Me sorprendió de gran manera como creció el hilo de la conversación.

Creo que a lo que Marioloko se refiere es a un problema que es común por lo menos en donde laboro, la inercia al cambio. Precisamente esta aplicación que anterior para el registro del aspirantes fue creada en PL/SQL. Despues decidieron hacer una versión java, que se parece mas bien a código PL/SQL traducido a java. El resultado fue por demás deficiente. Considero que son más factores que se consideran para elegir un framework además de la inercia al Cambio, como los puntos a los que se refiere greeneyed.

Remoh, al igual que tú me encanto Grails desde el momento en que decidí conocerlo, y considero que la tiempo en aprender a para sacarle todo su potencial se justifica con las ventajas que ofrece. Si la decisión dependiera únicamente de mi, optaría por Grails. Pero también considero que es importante hacer un balance de las características que ofrecen cada framework.

Por lo pronto estamos organizándonos para crear prototipos para tomar una decisión sobre la o las herramientas elegidas.