Estoy considerando crear mi propio sitio web usando Java y estoy tratando de decidir qué marco usar. Sin embargo, si hace una búsqueda rápida de marcos de trabajo Java, obtendrá más de 50 para elegir.
Mi sitio web solo va a ser para mi propio disfrute de construirlo al principio, pero si se vuelve popular, sería bueno que tuviera algo de escalabilidad, o al menos poder rediseñarlo.
¿Cuáles son las principales diferencias entre los marcos más populares? ¿Hay casos en los que uno supera significativamente a los demás? Por ejemplo, aplicaciones empresariales de alto tráfico frente a pequeñas aplicaciones de bajo tráfico. También me pregunto si algunos son mucho más fáciles de aprender y usar que otros.
¿Hay alguien que tenga experiencia con algunos de estos marcos y pueda hacer una recomendación? ¿La gran cantidad de opciones solo sirve como una advertencia temprana para evitar el desarrollo web basado en Java siempre que sea posible?
Respuestas:
He usado Tapestry 3 , Wicket , Echo y JSF bastante extensa. Realmente te recomiendo que los revises y elijas el que te parezca más fácil y que se ajuste mejor a tu forma de trabajar.
De ellos, el más cómodo para mí para trabajar fue Wicket , debido a la naturaleza liviana de la construcción de componentes y la simplicidad de las plantillas de página. Eso es doblemente válido si está utilizando su propio código de base de datos en lugar de Hibernate o algún otro marco (nunca estuve completamente satisfecho con Wicket Hibernate o Spring Integration).
Echo es genial si no te importa escribir todo tu diseño en Java. Sé que ahora es diferente, pero sigo pensando que ese producto sirve a un nicho bastante estrecho. También parece que cambian el modelo de desarrollo con cada lanzamiento importante.
Tapestry es un gran producto, pero obviamente es muy diferente de los demás en términos de modelo de desarrollo, ya que está dirigido principalmente por un tipo. Howard Lewis Ship es sin duda bastante inteligente, pero estoy decepcionado con su decisión de básicamente olvidar la compatibilidad con versiones anteriores de cada lanzamiento. Una vez más, sin embargo, para sus necesidades, esto puede no importar, y siempre me ha gustado trabajar con los productos Tapestry.
JSF ha estado disponible durante años y todavía se siente como algo que Struts tipo de construyó para solucionar todos los problemas de Struts. Sin entender realmente todos los problemas con Struts. Todavía tiene una sensación de inacabado, aunque el producto es obviamente muy flexible. Lo uso y le tengo algo de cariño, con grandes esperanzas en su futuro. Creo que la próxima versión (2.0) que se entregará en JEE6 realmente lo traerá por sí solo, con una nueva sintaxis de plantilla (similar a Facelets) y un modelo de componente simplificado (componentes personalizados en solo 1 archivo ... finalmente).
Y, por supuesto, hay un millón de marcos y herramientas más pequeños que obtienen sus propios seguidores ( Velocity para necesidades básicas, JSP sin procesar , Struts, etc.). Sin embargo, generalmente prefiero los marcos orientados a componentes.
Al final, recomendaría simplemente echar un vistazo a Tapestry, Wicket y JSF y elegir el que se sienta mejor para usted. Probablemente encontrará rápidamente uno que se adapte a su forma de trabajar.
fuente
Mi favorito es Spring Framework. Con 2.5 Spring MVC es tan increíble, con nuevas anotaciones, convención sobre características de configuración, etc.
Si solo está haciendo algo súper simple, también podría intentar usar la API de Servlet normal y no molestarse con un marco.
fuente
Recomiendo el marco Wicket orientado a componentes . Le permite escribir su aplicación web en un código Java antiguo y sencillo, puede usar POJO como modelo para todos los componentes y no necesita perder el tiempo con archivos de configuración XML enormes.
¡Había desarrollado con éxito una aplicación de banca en línea con Struts cuando descubrí Wicket y vi lo fácil que puede ser el desarrollo de aplicaciones web!
fuente
Recientemente comencé a usar Stripes Framework . Si está buscando un marco basado en solicitudes que sea realmente fácil de usar, pero que no imponga ningún límite a lo que está haciendo, lo recomiendo encarecidamente.
Es similar a los struts, pero va mucho más allá. Incluso hay algunos proyectos de complementos que le permiten usar hibernate o jpa con muy poca configuración.
Hay muchos marcos buenos por ahí, aunque he escuchado que wicket también es bueno, pero no lo he usado.
fuente
No lo he probado yo mismo, pero creo que
http://www.playframework.org/
Tiene mucho potencial...
viniendo de php y asp clásico, es el primer framework web java que me suena prometedor ...
fuente
ACTUALIZACIÓN: Tapestry 5.2 está disponible, por lo que no está abandonado, como parecía estarlo anteriormente. Mi experiencia es con Tapestry 4, no con 5, por lo que su kilometraje puede variar. Mi opinión sobre Tapestry ha cambiado a lo largo de los años; He modificado esta publicación para reflejarlo.
Ya no puedo recomendar Tapestry como lo hacía anteriormente. Tapestry 5 parece ser una mejora significativa, pero mi principal problema con Tapestry no es la plataforma en sí; es con la gente que está detrás.
Históricamente, cada actualización importante de la versión de Tapestry ha roto la compatibilidad con versiones anteriores con prejuicios extremos, mucho más de lo que cabría esperar. Esto parece deberse a la incorporación de nuevas técnicas o tecnologías de codificación que requieren reescrituras importantes.
Howard Lewis Ship (el autor principal de Tapestry) es sin duda un desarrollador brillante, pero no puedo decir que me preocupe por su gestión del proyecto Tapestry. El desarrollo de Tapestry 5 comenzó casi inmediatamente después del envío de Tapestry 4. Por lo que puedo decir, Ship prácticamente se dedicó a eso, dejando Tapestry 4 en manos de otros colaboradores, que creo que no son tan capaces como Ship. Después de haber hecho el doloroso cambio de Tapestry 3 a Tapestry 4, sentí que me habían abandonado casi de inmediato.
Por supuesto, con el lanzamiento de Tapestry 5, Tapestry 4 se convirtió en un producto heredado. No tendría ningún problema con esto si la ruta de actualización no fuera tan brutal nuevamente . Así que ahora nuestro equipo de desarrollo se encuentra en una posición poco envidiable: podríamos seguir usando una plataforma web esencialmente abandonada (Tapestry 4), hacer la atroz actualización a Tapestry 5 o renunciar a Tapestry por completo y reescribir nuestra aplicación usando otra plataforma. Ninguna de estas opciones es muy atractiva.
El tapiz 5 supuestamente está escrito para reducir la probabilidad de que se rompa la actualización a partir de este momento. Un buen ejemplo son las clases de página: en encarnaciones anteriores, las clases de página descendían de una clase base proporcionada por Tapestry; Los cambios de API incompatibles en esta clase fueron la causa de una gran cantidad de problemas de compatibilidad con versiones anteriores. En Tapestry 5, las páginas son POJO que se mejoran en tiempo de ejecución con el "polvo mágico del tapiz" a través de anotaciones. Por lo tanto, siempre que se mantenga el contrato para las anotaciones, los cambios en Tapestry no afectarán las clases de su página.
Si esto es correcto, entonces escribir una nueva aplicación usando Tapestry 5 podría resultar bien. Pero personalmente, no tengo ganas de volver a poner la mano en el quemador.
fuente
Descargo de responsabilidad: trabajo en Vaadin (anteriormente IT Mill)
Si está haciendo algo RIAish, es posible que desee echar un vistazo a Vaadin . Es un marco de trabajo AJAX orientado a la interfaz de usuario de código abierto que, para mí, es agradable de usar (yo mismo provengo de PHP).
Hay un estudio de caso que compara hacer la misma aplicación (es decir, dos aplicaciones con el mismo conjunto de características) en Icefaces y Vaadin. En pocas palabras, afirma que el desarrollo de la interfaz de usuario fue considerablemente más rápido.
Aunque el estudio está alojado en la wiki de la empresa, puedo asegurar que es objetivo, genuino y veraz, aunque no puedo obligarlos a creerme.
fuente
Después de un largo tiempo de probar varias soluciones, para mí resultó ser:
Spring MVC para la capa de presentación y controlador (sin embargo, NO Spring Webflow, porque mis flujos se basan en ajax)
jQuery para todas las cosas del lado del cliente
Spring Security para el, bueno, aspecto de seguridad
Hibernar / JPA2
Embarcadero por el bien de las continuaciones (cometa)
Un mes de una curva de aprendizaje extraordinariamente empinada, pero ahora estoy feliz.
También me gustaría mencionar que estaba a un pequeño paso de saltarme todas esas cosas de Java y aprender Scala / LIFT en su lugar. En lo que a mí respecta, todo en Java que esté relacionado con el desarrollo web de vanguardia (cometa, comunicación asíncrona, seguridad (sí, ¡incluso con Spring Security!)) Todavía es un truco (prueba que estoy equivocado con evidencia, por favor !). Para mí, Scala / LIFT parece ser una solución más lista para usar y todo en uno.
La razón por la que finalmente decidí no ir con Scala es
Como líder de proyecto, debo considerar que los recursos humanos y los desarrolladores de Java son mucho más fáciles de encontrar que los desarrolladores de Scala.
para la mayoría de los desarrolladores de mi equipo, el concepto funcional de Scala, tan excelente como es, es difícil de entender
Saludos Er
fuente
También he escuchado cosas buenas sobre Spring Framework. Sin embargo, en general, la mayoría de los marcos web de Java que he visto no me han impresionado (especialmente Struts).
Para una aplicación simple, definitivamente consideraría usar servlets y JSP "sin procesar" y no me preocuparía por adoptar un marco. Si los servlets están bien escritos, debería ser sencillo en el futuro migrar a un marco si es necesario cuando la aplicación crezca en complejidad.
fuente
¡Mi elección es Wicket!
fuente
Todos ellos, ese es el problema ;-)
fuente
Creo que para sus modestos requisitos, solo necesita codificar servlets o páginas jsp simples que puede servir desde el servidor Tomcat. No creo que necesite ningún tipo de marco web (como struts) para los datos personales del sitio web
fuente
Decir "use JSF" es un poco demasiado simple. Cuando decida usar JSF, debe elegir una biblioteca de componentes encima. ¿Utilizará MyFaces Tomahawk, Trinidad, Tobago ( http://myfaces.apache.org/ )? ¿O tal vez ICEfaces ( http://www.icefaces.org/ )? Ah, y si usa ICEfaces, ¿usará JSP o Facelets para sus vistas?
En mi opinión, es muy difícil de decir. Nadie tiene tiempo para evaluar todas las alternativas prometedoras, al menos en los proyectos en los que trabajo, porque no son lo suficientemente grandes como para hacer fases de evaluación de tres meses. Sin embargo, debe buscar algunos que tengan una comunidad grande y activa y que no desaparezcan en un año. JSF existe desde hace algún tiempo, y dado que es empujado por el sol, seguirá existiendo por un tiempo más. No puedo decir si es la mejor opción, pero será buena.
fuente
http://zkoss.org - el bueno
fuente
Para sitios de alto tráfico, usaría un marco que no administra el estado del cliente en el servidor: Wicket, JSF y Tapestry administran el estado del cliente en el servidor. Solo usaría esos marcos (Wicket es mi favorito) si la aplicación se parece más a una aplicación de escritorio. Pero trataría de usar un enfoque REST + AJAX más escalable y simple.
Spring MVC sería un candidato, pero desde Spring MVC 3 tiene un extraño modelo de programación sobrecargado de anotaciones que no utiliza los beneficios de la escritura estática. Hay otras cosas desagradables como los parámetros de salida en los métodos combinados con un retorno habitual, por lo que hay dos canales de salida de un método. Spring MVC también tiende a reinventar la rueda y tendrá más que configurar en comparación con otros marcos. Realmente no puedo recomendar Spring MVC aunque tiene algunas buenas ideas.
Grails es una forma conveniente de usar Spring MVC y otros marcos establecidos como Hibernate. Codificar es divertido y verá resultados rápidamente.
Y no olvide que la API de Servlet con algunos pequeños ayudantes como FreeMarker para crear plantillas es muy poderosa.
fuente
He evaluado bastantes marcos y Vaadin ( http://vaadin.com/home ) se ha filtrado hasta la cima.
Debería al menos darle una breve evaluación.
¡Salud!
fuente
Mi elección sería Wicket (para proyectos grandes y una base de usuarios predecible), GWT (para proyectos grandes que son en su mayoría públicos) o simplemente un marco de servicio (como Jersey / JAXRS) junto con un kit de herramientas JavaScript (para proyectos pequeños y medianos) .
fuente
Recomiendo Seam, especialmente si necesitas persistencia.
fuente
Vea algunos comentarios sobre algunos marcos de aplicación de Java (segundo párrafo):
http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html
fuente
Para una GUI rápida y elegante , puede usar JSF con la biblioteca Richfaces . Los componentes de la interfaz de usuario de Richfaces son fáciles de usar y tienen referencias prácticas disponibles con demostración de código en el sitio de demostración. Probablemente más adelante, cuando su sitio tenga más datos que manejar y mucha información tenga que ser procesada en la base de datos, podrá conectar cualquier marco de acceso a la base de datos (ORM).
fuente
No puedo creer que nadie haya mencionado a GWT
fuente
Mi forma favorita de elegir aplicaciones realmente simples es Apache VelocityTools (VelocityLayoutServlet) con Velosurf ( http://velosurf.sourceforge.net ).
Para aplicaciones más complejas, Spring MVC o Struts 2.
fuente
Pruebe HybridJava, que es mucho más simple que cualquier otra cosa.
fuente
Yo diría vaadin o wicket
fuente