¿Está eligiendo un marco web Java ahora? [cerrado]


149

estamos en la etapa de planificación de la migración de un gran sitio web que se basa en un marco mvc desarrollado a medida a un marco web basado en java que proporciona soporte integrado para ajax, contenido multimedia enriquecido, mashup, diseño basado en plantillas, validación, máximo html / separación de código java. Grails parecía una buena opción, sin embargo, no queremos utilizar un lenguaje de programación. Queremos seguir usando java. El diseño basado en plantillas es una preocupación principal, ya que tenemos la intención de utilizar esta aplicación web con varios sitios web con una funcionalidad similar pero una apariencia y un estilo radicalmente diferentes.

¿La solución basada en portal se adapta bien a este problema?

Cualquier información sobre el uso de "Spring Roo" o "Play" será muy útil.

Encontré publicaciones similares como esta , pero tiene más de un año. ¡Las cosas seguramente han cambiado mientras tanto!

EDIT 1: ¡ Gracias por las excelentes respuestas! Este sitio se está convirtiendo en la mejor fuente de información para programadores en las trincheras. Sin embargo, esperaba más información sobre el uso de un dúo portal-cms. Jahia luce bien. ¿Algo similar?


1
"no queremos usar un lenguaje de scripting", es una pena, ¿por qué si puedo preguntar? si te gusta el framework Play, deberías probar JRuby con Rails. No es Java simple, pero es muy fácil llamar a clases de Java desde JRuby.
Luke

2
Grails (es decir, Groovy) funciona muy bien con Java, no hay necesidad de tener miedo.
Erich Kitzmueller

4
@hbagchi: Solo curiosidad; 4 meses después, ¿con qué marco te decantaste? ¿Feliz con eso?
Jonik

1
¿No es esta una pregunta de 'wiki de la comunidad'?
mickthompson

11
"pero tiene más de un año. ¡Las cosas seguramente han cambiado mientras tanto!" ... ¡Oh, sí, Dios no permita que uses tecnología que tenga más de 12 meses! La Bala de Plata seguramente se ha inventado mientras tanto ... :-)
ObiWanKenobi

Respuestas:


146

¿La solución basada en portal se adapta bien a este problema?

Personalmente, me mantendría alejado de las grandes soluciones de Portal (a menudo son asesinos de la productividad). Sin embargo, he escuchado cosas buenas sobre Gatein, pero no tengo ninguna experiencia real con eso.

Cualquier información sobre el uso de "Spring Roo" o "Play" será muy útil.

Acerca de Spring Roo, he leído respuestas anteriores como Spring roo Vs (Wicket y Spring) y otras cosas en Internet, pero todavía no estoy convencido (tal vez no lo entiendo), no estoy seguro de su madurez Y, lo que es más importante, realmente me pregunto qué está haciendo SpringSource con Grails y Roo (no, Grails vs Roo, ¿por qué SpringSource está impulsando dos tecnologías muy similares? no me convence de que ambos sobrevivirán).

No puedo decir mucho sobre Play. He visto la demostración como todos, pero me gustaría leer comentarios de la vida real. Hasta entonces, esperaré.

Encontré publicaciones similares (...). ¡Las cosas seguramente han cambiado mientras tanto!

Sí y no :) Pero entremos en el infierno de los frameworks de presentación: no hay una respuesta única a tu pregunta (como hace un año), hay docenas de frameworks por ahí y no hay un ganador claro. Solo por citar algunos:

  • JSF: Muchos escépticos sobre este marco basado en componentes, incluyéndome a mí, así que no soy el mejor para hablar de ello, pero ...
  • JSF 2 (+ CDI / Weld): los escépticos de JSF son animados ( por Gavin King ) a "echar un segundo vistazo". De hecho, creo que JSF 2 es una gran mejora, especialmente con CDI, pero ... todavía es bastante nuevo (entiéndelo, carece de comentarios). Si quieres adoptar Java EE 6, échale un vistazo.
  • Wicket: Otro marco basado en componentes que está recibiendo más atención. Escucho principalmente cosas buenas al respecto: más simple que JSF, diseño agradable, alta capacidad de prueba, amigable para el diseñador HTML, etc.
  • Tapestry: Simplemente no lo hagas (consulta ¿Por qué dejaste de usar Tapestry? )
  • Struts 2, Spring MVC, Stripes: marcos basados ​​en acciones. Todo decente y cubrirá sus necesidades (personalmente, me gusta Stripes y su convención sobre el enfoque de configuración, vea Stripes vs. Struts2 para tener una idea).
  • GWT, Flex, Grails: Quizás no sea lo que estás buscando. Realmente no puedo hablar sobre (versiones recientes) de Flex y GWT, pero sé que Grails tiene algunos fanáticos .

En realidad, sugeriría echar un vistazo a las presentaciones de Matt Raible , realmente hizo un gran trabajo comparando marcos web, mostrando sus fortalezas y debilidades, recopilando datos y números, mostrando tendencias ... Recomiendo:

De verdad, echa un vistazo a estas presentaciones, te ayudarán a encontrar un marco adecuado (no hay una respuesta única pero puedes restringir la elección por eliminación) y podrían cambiar tu punto de vista.


Buen trabajo, me he retirado :). +1
Adeel Ansari

El reciente lanzamiento de Matt desde Java Web F / Ws fue terrible. Si recuerdo, los struts tenían prácticamente la misma puntuación de f / ws mucho más ricos y potentes. No hay forma de que alguien pueda considerar algo tan simple como los puntales dignos de una puntuación que está solo unos pocos puntos por detrás de GWT o Wicket.
mP.

3
Sí, me doy cuenta de que a muchas personas no les gustó mi "matriz" o mi lógica para sus calificaciones. Al final, lo que esperaba hacer con esta matriz era simplemente resaltar una técnica para elegir un marco web. Puede leer sobre la lógica detrás de mis calificaciones en la siguiente publicación de blog: raibledesigns.com/rd/entry/how_i_calculated_ratings_for
Matt Raible

La presentación de Matt Raible sobre la comparación de JSF, Spring MVC, Stripes, Struts 2, Tapestry y Wicket es bastante antigua ...
Nerrve

1
@iberck, he estado experimentando con AngularJS recientemente. Honestamente, creo que sombreará la mayoría, si no TODOS, los marcos web actuales sin exagerar. Es simplemente un marco JS para el lado del cliente, entonces puede recuperar sus datos fácil y "eficientemente" desde el servidor usando REST. Pruébelo, sacudirá
Muhammad Gelbana

41

He estado usando Spring 3 y Jquery por un tiempo, pero escuché sobre Play y lo intenté. Realmente me gusta, Play encaja perfectamente entre algo como PHP y los marcos de trabajo de Java de alta resistencia como Spring.

Las cosas que más me gustan del juego son:

  • Es muy fácil hacer despegar una aplicación de juego, tienes que ir bastante lejos con la codificación y la configuración para obtener una aplicación simple en la pantalla con Spring (aunque Spring 3 lo ha hecho mucho más fácil).
  • Spring Security es impresionante, pero tiene un costo de complejidad. El módulo de seguridad de Play es muy simple y cubre las necesidades de probablemente el 90% de las aplicaciones que existen.
  • Puede hacer un cambio de código y presionar actualizar en el navegador para ver el cambio como con PHP en lugar de tener que hacer todo el redespliegue con marcos basados ​​en Servlet.
  • Los mensajes de error se muestran de forma agradable y no tan crípticos la mayor parte del tiempo. Play todavía necesita trabajar en su manejo de errores
  • Hay un mecanismo de complementos para Play que es bastante simple.
  • La persistencia de objetos se hace muy bien porque una base de datos en memoria y JPA viene con el marco, por lo que no hay configuración de herramientas de persistencia de objetos externos. Pasar de la base de datos en memoria a un RDBMS real es un cambio de una línea en el archivo de configuración.
  • La configuración de MVC está muy bien. La clase Model que amplía para crear sus objetos de dominio se integra con el administrador de entidades JPA. No son solo de POJO.
  • La asignación de URL a los controladores es simple y flexible y todo en un archivo de "rutas".
  • Siempre que crea un proyecto, Play maneja todas las dependencias de jar y Play tiene una utilidad para eclipsar (o cualquier IDE que desee) el proyecto para que se importe directamente a su IDE favorito.

Cosas que no me gustan de Play

  • La documentación aún no está completa, todavía existen muchas características indocumentadas.
  • El marco es el servidor, por lo que debe dedicar un puerto a cada aplicación. Creo que alguien está trabajando en un complemento de host virtual, pero aún no lo he visto en acción.
  • Es joven, el proyecto es increíble y la tecnología es increíble, pero realmente necesita más desarrolladores. Me encantaría dedicarle un tiempo, ya veremos.

17

La mejor opción para mí es Wicket . Separación clara de marcado y código java. Componentes muy fáciles de escribir y usar. Fácil de usar Ajax, capacidad de prueba. Puede depurar directamente en sus páginas / componentes y no obtener mensajes de error crípticos de su implementación JSF;)

También hay un buen wicket de comparación <--> JSF en términos de rendimiento


4
+1 Por no hablar de la orientación POO pura con herencia, polimorfismo y composición. ¡Además, archivos XML-config gratis!
Xavi López

3
Es interesante que las personas voten negativamente aquí porque no les gusta el marco sugerido. No solo mi respuesta de Wicket, casi todos tienen algunos votos
negativos

13

Las tres opciones principales para mí son (alfabéticamente):

Ellos:

  • tener un buen soporte ajax
  • le permiten crear sitios web reales, no aplicaciones (como GWT)
  • estable, bien documentado, ampliamente utilizado
  • MVC
  • Java puro
  • fácil integración con Spring como middleware

17
No tengo idea de cómo se puede afirmar que JSF se puede utilizar para "hacer sitios web reales". Cualquier framework que obligue al uso de POST pierde inmediatamente en este sentido.
Stefan Tilkov

3
He desarrollado "sitios web reales" con JSF y los he usado sin ningún problema. Además, el uso de POST es obligatorio solo cuando está publicando algo. Siempre es libre de utilizar la navegación GET simple. Teóricamente, es incorrecto usar GET si está modificando un recurso, ¿no es así?
Bozho

además, tendrías que rechazar a Pascal, también por sugerir JSF;)
Bozho

3
No te ofendas, pero esto suena como una lista de 'cosas' que habrías visto hace años, así que me sorprende verlo. En mi experiencia, desde entonces la mayoría ha superado esos pasos en falso. Supongo que si ya eres un experto en estos, serían excelentes opciones, pero me preocuparían los programadores de O&M que tienen que hacerse cargo después de que los expertos abandonen el proyecto. En mi opinión, nadie está aprendiendo realmente estas cosas.
Manius

1
Esta línea de comentarios es un poco divertida. Por supuesto, JSF se puede utilizar perfectamente para sitios web, y tiene soporte de primera clase tanto para GET como para POST. Utilice lo que sea más apropiado para la situación actual. De hecho, como indica Bozho, si modifica un recurso, no use GET; de lo contrario, no dude en hacerlo.
Arjan Tijms


10

En contraste con otras respuestas, me gustaría resaltar las desventajas (en mi humilde opinión) de los marcos web populares:

JSF2 : lanzado y ya envejecido. Aún quedan pocas noticias / artículos / publicaciones en blogs / experiencias. Soy escéptico Todavía esperando la próxima versión importante de Richfaces / Icefaces que sea totalmente compatible con jsf 2; actualmente solo se pueden descargar versiones alfa.

Struts 2 : parece ser solo algo bueno si todavía confía en struts y desea refactorizar la mayor parte de su código. De lo contrario: no lo hagas.

GWT - No me gusta el enfoque de una sola página y java-> javascript. No estoy seguro de si se puede lograr fácilmente una sesión: múltiples vistas / ventanas. Para mí, este marco debería usarse para aplicaciones de Internet ricas en una sola ventana para usuarios masivos.

Wicket - Buen enfoque, pero un poco detallado y muy poca documentación disponible (excepto el buen wicket en el libro de acción, pero esto cubre solo 1.3). Además, para mí carece de grandes proyectos que se construyan sobre él. Y actualmente no puedo ver hacia dónde se dirige el camino del portillo o si ya se ha llevado a un callejón sin salida.

Spring MVC : no probé esto todavía, pero debe incluir muchos frascos (desorden de primavera) en su ruta de clase para trabajar con este marco correctamente. Y se basa en JSP (en la mayoría de proyectos), que considero ya muerto. Y solo obtiene un marco MVC puro: todas las demás cosas (ajax y otras) deben implementarse / integrarse.

Stripes : un marco MVC pequeño y de bonito diseño, pero muy poca documentación, muy pocas confirmaciones / confirmaciones, muy pocas versiones, muy menos soporte de la industria, muy menos actividad en la lista de correo.

También tengo curiosidad si me perdí un marco importante (dejé Tapestry intencionalmente) que podría ser una opción para usted (y también para mí).


He descubierto que la mejor manera de manejar esto es similar a lo que han hecho los marcos web de Python: Elija y elija entre los mejores. Por ejemplo: Spring + JAX-RS
Adam Gent

Tus comentarios sobre GWT son incorrectos. Es bastante fácil tener muchas páginas separadas en lugar de una gran cosa. Inserte un enlace a otra página para iniciar otra "acción" y todo bien.
mP.

También estoy hablando de múltiples ventanas (o pestañas). ¿Es realmente posible usar más de una ventana usando la misma sesión simultáneamente?
MRalwasser

1
+1 ¿Por qué esta publicación recibió 2 voces negativas? ¡Las opiniones escépticas como estas son igualmente importantes (si no más) que las positivas! Y estos me parecen constructivos.
Piotr Sobczyk

8

He tenido un gran éxito con JAX-RS . Es el único Java Web Framework que tiene algún tipo de especificación JSR y múltiples implementaciones además de la especificación de servlet y portlet (aunque esto puede ser algo malo).

Una cosa que es mala y buena de Java es que puede elegir y combinar marcos (Python también tiene esta característica / problema). Es bueno porque no tienes que poner todos los huevos en una canasta.

Aquí hay una receta general de pila de aplicaciones web Java:

Javascript / Flash + Gestión de solicitudes / respuestas + Inyección de dependencias + Persistencia

Javascript: JQuery, Prototype, Dojo

Solicitud / respuesta: Spring MVC, Stripes y mi JAX-RS favorito (Jersey, Apache CXF)

Inyección de dependencia: Spring, Guice

Persistencia: JPA (Hibernate, almacenamiento de aplicaciones de Google), Hibernate, JDO y más.

También he tenido un gran éxito en el uso de AspectJ para hacer que Java "apesta menos". Al usar los mixins de Spring's @Configurable y AspectJ's ITD, puede obtener Rails como objetos de dominio (esto es de hecho lo que hace Roo, pero no necesita que Roo lo haga).


4
Estoy de acuerdo. Se necesita más tiempo para configurar su propia pila, pero luego obtiene exactamente lo que desea. Actualmente estoy usando jQuery, Jersey, Spring y JPA2. JAX-RS es genial porque tienes un control total sobre cuál es tu respuesta.
Brian DiCasa

6

Descubrí que las rayas son realmente efectivas y sorprendentemente livianas ... su objetivo es ser más liviano que los puntales . Escuché de amigos que son desarrolladores web a tiempo completo que no vale la pena molestarse con JSF, aunque no tengo experiencia de primera mano, y no puedo respaldar eso con ejemplos (!).


5

Eche un vistazo a RESThub , que sigue los mismos principios que Play! pero implementado reutilizando algunos marcos / herramientas de nivel empresarial como Maven 3 / Spring 3 / Jersey / jQuery.

RESThub es muy disruptivo en comparación con otros marcos, ya que es un conjunto de herramientas de pila completa, pero sin ningún MVC del lado del servidor o marcos basados ​​en servlets. En su lugar, usa una GUI basada en jQuery UI que usa servicios web JAX-RS (REST) ​​y un sistema de plantillas Javascript basado en embeddedJs.

Los servidores no tienen estado y usamos HTML5 sessionStorage para mantener la sesión en el lado del cliente. Este enfoque está diseñado para RIA y escalabilidad.

Se proporcionan algunas aplicaciones de demostración (incluso si están en construcción).


3

JSF es un buen framewrok, pero JSF 1.2 careció de visión durante años desde su lanzamiento. JSF 2.0 parece prometedor y tiene muchas cosas nuevas agregadas de JSF 1.2 como soporte ajax, facelets, soporte de anotaciones y convenciones predeterminadas (menos XML), compilación de componentes fácil que 1.2.

También se integra bien con Spring, si le preocupa el soporte DI.


2

Respaldaría la recomendación de Spring. No soy un gran fan de GWT, no creo que el compilador cruzado de Java -> Javascript esté listo todavía. Estoy trabajando en una aplicación AJAX que usa Spring en el servidor y jQuery en el cliente. Aunque técnicamente no hay soporte "listo para usar" para jQuery, implementar un Spring-MVC AjaxView es muy simple y tomó alrededor de 25 líneas de código.


2

Quizás un poco tarde para el show, pero tengo que mencionar a Vaadin . La programación se realiza exclusivamente en Java, con un enfoque basado en componentes. La comunicación cliente-servidor tiene más que ver con la interacción del usuario que con el transporte de datos, toda la lógica empresarial reside en el servidor.


1
Yo uso vaadin, simplemente no es bueno para construir una aplicación compleja.
Radan


1

Creo que lo que buscas es algo parecido a Jahia. Es compatible con GWT, Mashups, contenido multimedia, etc.

http://www.jahia.org/cms/lang/en/home/Jahiapedia/Jahia_Templates http://www.jahia.net/downloads/jahia/jahia6.0.0/readme/index.html


¡Se ve bien! ¿Es esto de código abierto / gratuito para empresas? ¿Es esto muy utilizado?
cosmos

Tiene una versión comunitaria con todas las cosas básicas y una versión empresarial con algunas adiciones, etc. Visite este lugar jahia.com/jahia/Jahia
Syed M Shaaf



0

Algo que merece algo más que una viñeta son los frameworks RIA basados ​​en jugadores. Ex. Adobe Flex + Java (Por supuesto, esto puede depender un poco de si su "sitio" es realmente un "sitio" o más como una "aplicación", no haría un sitio de blog en Flex).

ajax,

En el sentido de AJAX como palabra de moda, Flex generalmente usa AMF (un protocolo binario que es más eficiente que los protocolos usados ​​por las aplicaciones AJAX), aunque también puede hacer cosas estrictamente AJAX con Flex. Entonces Flex es compatible con AJAX, pero también es compatible con "mejor que AJAX".

contenido rich media, mashup,

Dado que Flex se ejecuta en la plataforma Flash de 'máquina virtual', creo que es necesario agregar poco.

diseño basado en plantillas,

No estoy seguro de a qué se dirige exactamente, pero suena como Flex mxml.

validación,

Compatible, por supuesto, aunque puede que decida hacer algunas cosas personalizadas si quiere ser elegante. (No es que tengas que hacerlo). Lo bueno es que puedes ser tan sofisticado como quieras, o no.

separación máxima de código html / java

No puede separarse más usando un enfoque de desarrollo de 'máquina virtual' como Flex / Silverlight / JavaFX. Esto no solo le permite mantener su código de presentación separado de la lógica del lado del servidor y la capa de acceso a los datos, sino que garantiza que estén separados. La 'virtualización' de su entorno de desarrollo le brinda compatibilidad entre navegadores, una plataforma de destino consistente, no se preocupe por nuevos navegadores o lanzamientos de navegadores que rompan su aplicación, capacidades de depuración de primera línea similares a las de Java y un producto final de apariencia más profesional / impresionante .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.