framework java jsf seam wicket web-frameworks

java - framework - ¿Qué marco debería elegir-Seam, Wicket, JSF o GWT?



jboss seam framework (11)

Estoy debatiendo si usar Seam, Wicket, JSF o GWT como base para mi capa de presentación en un proyecto de Java.

Reduje mi selección de frameworks web de Java a este subconjunto en función de las consideraciones del mercado de trabajo, la novedad de la tecnología y las recomendaciones de otros usuarios de SO.

¿Qué factores debo tener en cuenta al decidir entre estos?

El único de los que he usado es JSF, por lo que no podré darle retroalimentación sobre los demás, pero esta es mi opinión sobre JSF. En mi experiencia, en el momento en que convertimos de JSF en JSP a JSF en facelets, la vida se hizo MUCHO más fácil, así que me centraré en los facelets. Además, parece que Seam y JSF no son mutuamente excluyentes.

Pros:

  • La creación de facelets xhtml components es simple, lo que promueve la reutilización.
  • Habilidades de plantillas decentes usando etiquetas incorporadas como ui: insert, ui: include y ui: decorate
  • Acceso simple a Spring beans a través de faces-config
  • Basado en XHTML para que los desarrolladores web que no están familiarizados con Java puedan seguir siendo efectivos
  • Buena biblioteca de widgets disponible en tomahawk / trinidad

Contras:

  • Solo solicitudes de publicación. Esto puede hacer que los marcadores sean difíciles.
  • No como ajax-y incorporado como GWT, pero esto puede ser reparado si se usa con Seam

De ninguna manera soy un experto en JSF / Facelets, así que estoy seguro de que hay otros que me he perdido. Con suerte, alguien más también elaborará.

Actualización para JSF 2.0:

  • Tiene capacidades de reutilización aún mejores con componentes compuestos
  • Las bibliotecas de widgets para 2.0 incluyen primos y escalas de mojarra
  • Permite obtener solicitudes y marcadores
  • Ha incorporado el soporte Ajax
  • Ver http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/ para más información sobre JSF 2

Empecé con JSF (1.1 y 1.2) y fue tan doloroso que decidí cambiar en los próximos proyectos. Investigué un poco y decidí probar Wicket, y fue un placer. También probé JSF 2 pero sigue siendo lo mismo.

Ambos son marcos de componentes, pero las cosas con Wicket son fáciles, mientras que con JSF son un completo desastre.

Wicket sobre JSF:

  • En Wicket HTML son HTML. JSF tiene sus propias etiquetas de marcado. La h: dataTable (para tablas) no tiene sentido. Créanme, Sun Engineers tuvo que estar borracho cuando lo diseñó.
  • En Wicket cosas como la seguridad,
  • Con JSF, la barra de navegación muestra la URL anterior. Realmente extraño.
  • JSF me parece muy pesado y con bibliotecas como Rich o Prime aún más.
  • A veces, parece imposible saber qué está sucediendo. Siempre terminas gritando en tu computadora porque no sabes por qué está JSF.

JSF sobre Wicket:

  • En Wicket, vas a escribir más Java (el enlace con HTML). Al menos, su IDE proporcionará soporte de refactorización y validación.
  • La administración de recursos en Wicket es un poco complicada.
  • Hay mucha más documentación y soporte para JSF

Un error común es que el tamaño de la sesión es un problema (porque los componentes gráficos se almacenan allí).

Con todo, si tiene que decidir solo entre Wicket y JSF, no hay dudas para mí, Wicket .

En un escenario a largo plazo, recomendaría usar tecnologías respaldadas por una especificación de Sun. Hasta ahora, se ha demostrado que proporciona múltiples implementaciones que resultan en una elección (frecuentemente también implementaciones de código abierto), además el comportamiento tiende a estar muy bien definido.

Eso lo ayudará en un escenario de mantenimiento que, con suerte, su código terminará a tiempo. El código bien escrito vive para siempre :)

En este escenario particular, sugeriría JSF. Solo he probado la implementación de Apache de 1.1, pero dolió estar encima de JSP. Tenemos que revisarlo pronto, espero ver tener JSF en facelets.

Gracias chicos de wicket por mantenerse sobrio y mantener esta discusión. Soy un usuario de wicket y me encanta. Mis principales razones son:

  1. Es un marco de componentes. Me encanta trabajar con componentes en lugar de páginas completas.

  2. Puedo dejar que los diseñadores trabajen en las plantillas y páginas mientras trabajo en las partes de Java

  3. No hay nada nuevo que aprender Es "solo java y solo HTML"

  4. Me gusta su mecanismo de retroceso ajax. Donde no hay soporte para Javascript en un navegador, especialmente en dispositivos móviles, vuelve al html simple y todo funciona.
  5. Su falta de configuración xml es un plus
  6. Es compatible con todo lo que quisiera en una aplicación web. por ejemplo, validación, internacionalización, soporte de botón de retroceso y URL de descanso entre otros

Mi experiencia previa es GWT y JSF 1.0

He usado GWT desde la versión 1.4 y JSF desde que salió la especificación 2.0.

GWT es un marco del lado del cliente, genera JavaScript desde Java. Su arquitectura sería un cliente-servidor puro, lo que significa:

  • Lo mejor es usar servicios de grano grueso
  • Todos los objetos que viajan al lado del cliente deben ser completamente serializables (significa que no hay carga lenta o el patrón OpenSessionInView)
  • Desde GWT 2.0 puede diseñar su interfaz gráfica de usuario utilizando xhtml, que es mucho más fácil en lo que respecta al diseño y estructuración de HTML
  • GWT tiende a favorecer la buena arquitectura, si lo estropeas, será malo refactorizar
  • La historia perfecta (botón de retroceso del navegador, URL de marcadores) es difícil , es probable que tengas que rodar la tuya, aunque es fácil piratear algo directamente

JSF es un marco basado en componentes, con un diseño de vista primero (código subyacente si lo desea):

  • Es más fácil hacer algún tipo de webapps (con estado, como carrito de compras)
  • JSF + Seam tiene soporte para conversaciones (piense en páginas tipo asistente que mantienen el estado en varias páginas)
  • Puede implementar OpenSessionInView, dependiendo de su pila. Probablemente no se recomienda si usa EJB para la capa de servicio / negocio
  • JSF2 tiene un excelente soporte para AJAX, y con un conjunto de componentes como RichFaces puedes construir webapps agradables
    • Pero si quieres un comportamiento exquisito de JavaScript, tendrás que escribir algunos javascript
  • JSF rastrea el estado de la IU actual en el lado del cliente o del servidor. Esta es una compensación entre el tráfico de red o la memoria del servidor.

Currículum:

  • GWT es más adecuado para aplicaciones web (piense en gmail) que requieren el mejor rendimiento del lado del cliente. Es fácil escribir componentes personalizados (usted escribe Java) y como su lado del servidor es solo una capa de servicio, puede ser completamente sin estado en el lado del servidor.
  • JSF es más adecuado para la mayoría de las aplicaciones CRUD que son más adecuadas para las cosas orientadas a los componentes: piense en un sistema de reserva de hotel / vuelo, una tienda en línea con un carrito de compras, etc.

He usado Wicket y GWT bastante. Nunca realmente aprendió a amar Wicket.

Mi ego blogueó al respecto http://salk31.blogspot.com/2009/07/wicket-ajax.html

Mirar a GWT 2.0 uiBinder hoy me recordó lo molesto que era en Wicket tener que hacer coincidir el árbol de componentes XML con el creado en Java. El giro de GWT en esto me parece mucho mejor.

No he usado Wicket durante más de un año, así que tal vez hayan solucionado un montón de esto, pero dado el moderno navegador y el soporte JS, no veo el sentido de hacer todo esto en el servidor (lo sé, conozco la localidad de datos).

Mi experiencia es, en orden cronológico:

Servlets sin procesar - (sí, hay mucho trabajo duro, pero era temprano y estábamos ansiosos de castores!)

JSP: pensé que era el beez neez en el momento en que salió (si supiéramos;))

Echo: marco impresionante, pero no para páginas que deben ser amigables para los motores de búsqueda (el mismo problema con GWT)

Wicket - Marco impresionante: los desarrolladores entienden completamente el concepto de OO (a diferencia de JSP y muchos otros) y han aplicado todas las sutilezas de OO habituales a este marco. Si aprecia la "reutilización", si aprecia la encapsulación, si aprecia la separación de las preocupaciones y si desea vincular su modelo al código UI sin tener que preocuparse por la clasificación de objetos u otra fealdad, ¡este es el marco para usted!

Seam es un marco de aplicación, no una capa de presentación. Originalmente fue desarrollado para hacer que JSF sea menos doloroso, pero se ha convertido en un marco de inyección de dependencia de propósito más general.

Creo que puedes usar Seam con JSF, Wicket y GWT. El soporte de JSF es primario y excelente; No estoy seguro de qué tan bien los otros dos son compatibles.

Dado que el enfoque de sus criterios parece ser la comerciabilidad de sus habilidades, le sugiero probar Seam y JSF a través de Facelets. JSF es un estándar bien aceptado y, de hecho, es agradable de usar si está utilizando Facelets. Puedes tener una elegante funcionalidad AJAX a través de Richfaces y Ajax4jsf. Seam está siendo más o menos estandarizado a través del JCP.

Si considera solo el mercado de trabajo, debe elegir JSF. Pero, creo que el futuro de RIA pertenece a GWT y gwt al igual que las tecnologías del lado del cliente.

Creo que el aspecto más obvio de GWT es que es mejor escalable que las tecnologías de capa de presentación del servidor como JSF, wicket. Debido a que el servidor no necesita almacenar el estado del cliente y la potencia de la CPU del cliente también se utilizan. Es una gran ventaja, no es necesario serializar el estado del cliente entre las computadoras del servidor para lograr un sistema tolerante a fallas.

JSF está en desuso (JSF ni siquiera aparece en la lista como marco para comparar cuándo los evangelistas comparan o hablan sobre los marcos web en 2010).

Ahora las aplicaciones full fledge a gran escala se crean usando GWT, YUI, JQuery, etc.

Leer algunos artículos sobre google y más arriba será obvio.

(TODOS LOS TRABAJOS en JSF son para admitir aplicaciones heredadas).