java - development - Wicket o Playframework?

playframework java

Question

Soy totalmente nuevo en el desarrollo web Java y me gustaría elegir un buen marco web Java para aprender. He encontrado algunos ecos realmente buenos con respecto al marco de Apache Wicket y el Playframework . Decidí ir por uno de ellos; pero necesito elegir ;-)

Entonces, ¿qué elegir y por qué?

EDITAR

Mis requerimientos:

• Tuve una buena experiencia en el desarrollo con Django, por lo que un marco similar sería genial,
• Necesito un marco que pueda interactuar con otras herramientas principales de Java (bibliotecas, herramientas, etc.) para poder aprovechar lo que realmente ofrece Java.

Answer 1

¡Jugar! está diseñado para ser cómodo para los desarrolladores que vienen de lenguajes de script como Python y PHP. Proporciona su propio sistema de compilación y scripts de gestión, algo así como Rails o Django. Las herramientas de construcción existentes y la infraestructura (como los repositorios de Maven comúnmente utilizados para la gestión de dependencias en Java-land) no se integrarán bien con Play.

Wicket será más cómodo para los desarrolladores que vienen del desarrollo de escritorio en Java. No proporciona herramientas especiales, por lo que será más fácil de integrar en una herramienta de compilación específica si tiene una preferencia (y hay muchas herramientas de compilación que proporcionan cosas como la recuperación de dependencias automatizada disponible en el ecosistema de Java).

Así que hay una gran diferencia entre las dos opciones :) Si puede determinar qué experiencia le beneficiaría más, la decisión debería ser bastante clara desde allí.

Answer 2

Estoy usando PLay! Mucho y he usado Wicket para un poco de evaluación. Mi experiencia es que tienes que escribir mucho más código para realizar el mismo trabajo con Wicket. Tienes más "indirección" con Wicket. Personalmente prefiero un código que tenga la menor "ceremonia" posible y que sea fácil de seguir.

¡El juego! los arquitectos también están agregando el soporte de Scala a Play !, lo que creo que es una gran idea, ya que Scala es totalmente compatible con el código y las bibliotecas de Java, pero es mucho más avanzado que Java.

Answer 3

Si su sistema es solo para nivel Web, ¡Juegue! El marco es muy adecuado. But , si sus modelos de datos no son solo para la web, tal vez sean exported as REST by Spring with CXF y consumidos por GWT u otros servicios web, y desea asegurarse de que los estados congruentes con el nivel web, Wicket (con Spring / hibernate) Es una buena opción.

Algo de lo que no me siento tan bien con Play! Es el mecanismo de almacenamiento en caché. Tiene que nombrar manualmente / insertar / recuperar / invalidar / purgar caché. Esto hará que toda la arquitectura sea propensa a errores. Mientras se ejecuta con spring / JPA (hibernate) / ehcache (u otros proveedores), puede definir una capa de almacenamiento en caché / dao consistente para la capa superior (web / REST ...), que no impondrá inconsistencias de estado.

Otra ventaja con wicket es que tiene soporte AJAX incorporado respaldado por Java. Aunque estos estados de AJAX se mantienen en el lado del servidor (y tal vez un poco lento), si no desea aprender JavaScript, aún puede crear una página AJAX ''no tan mala''.

Con Play! , Si no sabe acerca de JS y no quiere aprenderlo, no quiere manipular DOMs engorrosos, solo puede crear un sitio ''promedio''. ¡OTOH, si eres experto en JS / jQuery, puedes elegir Jugar! .

Answer 4

Wicket y Play son dos tipos de marcos muy diferentes.

El juego es un marco MVC con el que probablemente se sentirá familiarizado con Django. Al igual que Django, ofrece más que solo los bits web y proporciona un marco de ORM basado en JPA, herramientas de andamios y probablemente mucho más (no tengo experiencia práctica con él). Tienen un gran tutorial en su sitio, y probablemente verás las similitudes de Django allí.

Wicket es un marco orientado a componentes (como JSF y Tapestry) y se centra principalmente en el diseño orientado a objetos. También es MVC, per se, pero las páginas generalmente se crean al componer componentes independientes y reutilizables (Vista y Controlador, Modelos conectables). Estos componentes pueden extenderse por herencia y composición estándar, y el marcado se separa del código de forma muy clara y se modifica fácilmente.

Wicket puede administrar las devoluciones de llamadas y el estado de los eventos de forma automática, de modo que no tenga que pensar las URL en absoluto, sin importar qué tan compleja sea su página. Un ejemplo rápido para un botón en el que se puede hacer clic y que desaparece cuando se hace clic (muy útil):

 // In a page constructor
add(new Link("link") {
public void onClick() {
setVisible(false);
}
});

Quiero enfatizar que no tienes que usar el estado del lado del servidor, y que es muy posible usar Wicket como un marco MVC "normal" si quieres (y sí, es fácil obtener URLs bonitas).

El proyecto Wicket se enfoca solo en el marco web principal y no hay "detalles" adicionales como el soporte especial de ORM o los andamios. Personalmente estoy de acuerdo con la filosofía del proyecto Wicket aquí, pero para los nuevos desarrolladores que vienen al framework, hacer cosas "simples" como una tabla clasificable y paginable puede ser un poco desalentador, ya que los componentes precompilados son un poco escasos. La curva de aprendizaje y productividad para Wicket puede ser un poco empinada, pero la ventaja es que una vez que haya creado componentes (y "comportamientos" - historia más larga) que se ajusten a sus necesidades, son extremadamente reutilizables.

Aunque personalmente amo a Wicket, tengo el presentimiento de que probablemente te irá mejor con Play. Su pregunta indica que desea un "Django" con acceso a las bibliotecas de Java, y en ese caso creo que Play (o algún otro Java MVC) es la opción segura. Por otro lado, tal vez has estado usando Django porque no sabías lo increíblemente poderoso que es Wicket. ;) Si proporciona más información sobre su proyecto, podremos darle una respuesta más calificada.

Como nodo lateral: como Play no es muy convencional (al menos por ahora), también consideraría a Grails que tiene un fuerte respaldo comercial e incluso más módulos listos para usar.