Quels sont les avantages et les inconvénients des différents frameworks Web Java?

J’ai beaucoup utilisé Tapestry 3 , Wicket , Echo et JSF . Je vous recommande vraiment de les regarder et de choisir celui qui vous semble le plus facile et qui correspond le mieux à votre façon de travailler.

Parmi eux, le plus confortable pour moi de travailler était Wicket , en raison de la légèreté de la création de composants et de la simplicité de la modélisation des pages. Cela est d’autant plus vrai si vous utilisez votre propre code de firebase database au lieu d’Hibernate ou de tout autre framework (je n’ai jamais été complètement satisfait de Wibet Hibernate ou de Spring Integration).

Echo est génial si vous ne voulez pas écrire toute votre mise en page en Java. Je sais que c’est différent maintenant, mais je pense toujours que ce produit sert un créneau assez étroit. Il semble que cela change aussi le modèle de développement avec chaque version majeure.

La tapisserie est un excellent produit, mais il est évidemment très différent des autres en termes de modèle de développement car il est principalement dirigé par un seul type. Howard Lewis Ship est sans aucun doute assez intelligent, mais je suis déçu de leur décision d’oublier fondamentalement la compatibilité avec chaque version. Encore une fois, cela n’a pas d’importance pour vos besoins, et j’ai toujours trouvé que les produits Tapestry étaient agréables à utiliser.

JSF est sorti depuis des années, et se sent toujours comme quelque chose qu’un gars de Struts a construit pour résoudre tous les problèmes de Struts. Sans vraiment comprendre tous les problèmes avec Struts. Il a toujours une sensation inachevée, bien que le produit soit évidemment très flexible. Je l’utilise et je l’aime, avec de grands espoirs pour son avenir. Je pense que la prochaine version (2.0) qui sera livrée dans JEE6 sera vraiment complète, avec une nouvelle syntaxe de modèle (similaire à Facelets) et un modèle de composant simplifié (des composants personnalisés dans un seul fichier … enfin).

Et, bien sûr, il existe un million de frameworks et d’outils plus petits ( Velocity pour les besoins de base, JSP brutes, Struts, etc.). Cependant, je préfère généralement les frameworks orientés composants.

En fin de compte, je vous recommande de regarder Tapestry, Wicket et JSF et de choisir celui qui vous convient le mieux. Vous en trouverez probablement un qui correspond à votre façon de travailler très rapidement.

Mon préféré est le cadre de spring. Avec 2.5 Spring, MVC est tellement génial, avec de nouvelles annotations, des fonctionnalités de configuration par-dessus, etc.

Si vous faites simplement quelque chose de très simple, vous pouvez aussi essayer d’utiliser l’API Servlet normale et ne pas vous soucier d’un framework.

Je recommande le framework Wicket orienté composants. Il vous permet d’écrire votre application Web dans le vieux code Java, d’utiliser des POJO comme modèle pour tous les composants et de ne pas avoir à vous soucier des énormes fichiers de configuration XML.

Lorsque j’ai découvert Wicket, j’ai développé avec succès une application de banque en ligne avec Struts et j’ai vu à quel point le développement d’applications Web pouvait être facile!

J’ai récemment commencé à utiliser le framework Ssortingpes . Si vous recherchez un cadre basé sur des requêtes, facile à utiliser, mais n’imposant aucune limite à ce que vous faites, je le recommande fortement.

C’est similaire aux jambes de force, mais cela va bien au-delà. Il existe même des projets de plug-in qui vous permettent d’utiliser hibernate ou jpa avec très peu de configuration.

Il y a beaucoup de bons frameworks, bien que j’aie entendu dire que le guichet est également bon, mais je ne l’ai pas utilisé.

Je n’ai pas essayé moi-même, mais je pense

http://www.playframework.org/

a beaucoup de potentiel …

venant de PHP et ASP classique, c’est le premier framework Web Java qui me semble prometteur ….

MISE À JOUR: Tapestry 5.2 est sorti, donc il n’est pas abandonné, comme il semblait auparavant. Mon expérience est avec Tapestry 4, pas 5, donc votre kilométrage peut varier. Mon opinion sur Tapestry a changé au fil des ans; J’ai modifié ce post pour le refléter.

Je ne peux plus recommander Tapestry comme je l’ai fait précédemment. Tapestry 5 semble être une amélioration significative, mais mon principal problème avec Tapestry n’est pas avec la plate-forme elle-même; c’est avec les gens derrière.

Historiquement, toutes les mises à jour majeures de Tapestry ont été incompatibles avec les préjugés extrêmes, bien plus que ce à quoi on pouvait s’attendre. Cela semble être dû à l’intégration de nouvelles techniques de codage ou de nouvelles technologies nécessitant d’importantes réécritures.

Howard Lewis Ship (l’auteur principal de Tapestry) est certainement un développeur shiny, mais je ne peux pas dire que je me soucie de sa gestion du projet Tapestry. Le développement de Tapestry 5 a commencé presque immédiatement après l’expédition de Tapestry 4. D’après ce que je peux dire, Ship s’est beaucoup consacré à cela, laissant Tapestry 4 entre les mains d’autres consortingbuteurs qui, à mon avis, ne sont pas aussi capables que Ship. Après avoir fait le passage douloureux de Tapestry 3 à Tapestry 4, j’ai senti que j’avais été abandonné presque immédiatement.

Bien sûr, avec la sortie de Tapestry 5, Tapestry 4 est devenu un produit hérité. Cela ne me poserait pas de problème si le chemin de mise à niveau n’était pas si brutal à nouveau . Notre équipe de développement est donc dans une situation plutôt peu enviable: nous pourrions continuer à utiliser une plate-forme Web essentiellement abandonnée (Tapestry 4), mettre à jour Tapestry 5 ou abandonner entièrement Tapestry et réécrire notre application en utilisant une autre plate-forme. Aucune de ces options n’est très attrayante.

Tapestry 5 est censé avoir été écrit de manière à réduire le risque de rupture de mise à jour à partir de ce moment. Un bon exemple est dans les classes de page: dans les incarnations précédentes, les classes de page sont issues d’une classe de base fournie par Tapestry; Les modifications incompatibles de l’API dans cette classe ont été à l’origine d’un grand nombre de problèmes de compatibilité descendante. Dans Tapestry 5, les pages sont des POJO qui sont améliorés lors de l’exécution avec la «poussière de fée de la tapisserie magique» via des annotations. Tant que le contrat pour les annotations est maintenu, les modifications apscopes à Tapestry n’affecteront pas vos classes de page.

Si tel est le cas, l’écriture d’une nouvelle application à l’aide de Tapestry 5 pourrait bien se révéler. Mais personnellement, je n’ai pas envie de remettre ma main sur le brûleur.

Disclamer: Je travaille chez Vaadin (anciennement IT Mill)

Si vous faites quelque chose de RIAish, vous pourriez vouloir regarder Vaadin . Il s’agit d’un framework AJAX orienté interface utilisateur open source qui, pour moi, est agréable à utiliser (je viens de chez PHP).

Il y a une étude de cas qui compare la même application (c.-à-d. Deux applications avec le même ensemble de fonctionnalités) dans Icefaces et Vaadin. En bref, le développement de l’interface utilisateur est considérablement plus rapide.

Même si l’étude est hébergée sur le wiki de l’entreprise, je peux vous assurer qu’elle est objective, authentique et véridique, même si je ne peux pas vous forcer à me croire.

Après avoir longuement testé différentes solutions, il s’est avéré que:

• Spring MVC pour la couche présentation et contrôleur (NO Spring Webflow, car mes stream sont basés sur ajax)

• jQuery pour toutes les choses côté client

• Spring Security pour l’aspect sécurité

• Hibernate / JPA2

• Jetée pour des suites (comète)

Un mois d’apprentissage très rapide, mais maintenant je suis content.

Je voudrais aussi mentionner que je ne suis pas loin de sauter tous ces trucs Java et d’apprendre Scala / LIFT à la place. En ce qui me concerne, tout en Java qui est lié au développement web de pointe (comète, communication asynchrone, sécurité (oui, même avec Spring Security!)) Est encore un peu un hack (me prouver par des preuves, !). Pour moi, Scala / LIFT semble être une solution plus prête à l’emploi et tout-en-un.

La raison pour laquelle j’ai finalement décidé de ne pas aller avec Scala est

• En tant que chef de projet, je dois considérer les ressources humaines et les développeurs Java sont beaucoup plus faciles à trouver que les développeurs Scala

• Pour la plupart des développeurs de mon équipe, le concept fonctionnel de Scala, aussi excellent soit-il, est difficile à comprendre.

Cheers Er

J’ai entendu de bonnes choses à propos du cadre de spring. En général, j’ai été déçu par la plupart des frameworks Web Java que j’ai consultés (en particulier, Struts).

Pour une application simple, je envisagerais certainement d’utiliser des servlets et des JSP “bruts” et de ne pas m’inquiéter de l’adoption d’un framework. Si les servlets sont bien écrites, il devrait être simple à l’avenir de porter sur une structure si nécessaire lorsque l’application devient plus complexe.

Mon choix est Wicket !!

Tous – c’est le problème 😉

Je pense que pour vos besoins modestes, il vous suffit de coder des servlets ou des pages jsp simples que vous pouvez utiliser depuis le serveur Tomcat. Je ne pense pas que vous ayez besoin de toute sorte de web-framework (comme des struts) pour les données personnelles du site Web

Dire “utiliser JSF” est un peu simple. Lorsque vous décidez d’utiliser JSF, vous devez choisir une bibliothèque de composants par-dessus. Utiliserez-vous MyFaces Tomahawk, Trinidad, Tobago ( http://myfaces.apache.org/ )? Ou peut-être ICEfaces ( http://www.icefaces.org/ )? Oh, et si vous utilisez ICEfaces, utiliserez-vous des JSP ou des Facelets pour vos vues?

À mon avis, c’est difficile à dire. Personne n’a le temps d’évaluer toutes les alternatives prometteuses, du moins dans les projets sur lesquels je travaille, car ils ne sont pas assez importants pour faire des phases d’évaluation de trois mois. Cependant, vous devriez chercher des personnes qui ont une grande communauté active et qui ne sont pas parties en un an. JSF est là pour quelque temps, et comme il est poussé par le soleil, il sera encore là. Je ne peux pas dire si c’est le meilleur choix, mais ce sera un bon choix.

http://zkoss.org – le bon

Pour les sites à fort trafic, j’utiliserais un framework qui ne gère pas l’état du client sur le serveur – Wicket, JSF et Tapestry gèrent l’état du client sur le serveur. Je n’utiliserais que ces frameworks (Wicket est mon préféré) si l’application doit ressembler davantage à une application de bureau. Mais j’essaierais cependant d’utiliser une approche REST + AJAX plus évolutive et plus simple.

Spring MVC serait un candidat, mais depuis Spring MVC 3, il possède un étrange modèle de programmation surchargé en annotations qui n’utilise pas les avantages du typage statique. Il y a d’autres choses laides comme les parameters de sortie dans les méthodes combinées avec un retour habituel, donc il y a deux canaux de sortie d’une méthode. Spring MVC a également tendance à ré-inventer la roue et vous aurez plus à configurer par rapport aux autres frameworks. Je ne peux pas vraiment recommander Spring MVC bien qu’il ait quelques bonnes idées.

Grails est un moyen pratique d’utiliser Spring MVC et d’autres frameworks établis comme Hibernate. Le codage est amusant et vous verrez rapidement des résultats.

Et n’oubliez pas que l’API Servlet avec quelques petites aides comme FreeMarker pour la modélisation est très puissante.

J’ai évalué pas mal de frameworks et Vaadin ( http://vaadin.com/home ) a percé tout le chemin.

Vous devriez au moins lui donner une brève évaluation.

À votre santé!

Mon choix serait Wicket (pour les grands projets et une base d’utilisateurs prévisible), GWT (pour les grands projets qui sont principalement orientés vers le public) ou simplement une structure de services (comme Jersey / JAXRS) avec une boîte à outils JavaScript (pour les petits et moyens projets) .

Je recommande Seam, surtout si vous avez besoin de persistance.

Voir quelques commentaires sur certaines applications Java Frameworks (deuxième paragraphe):

http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html

Pour une interface graphique rapide et sophistiquée, vous pouvez utiliser la bibliothèque JSF with Richfaces . Les composants d’interface Richfaces sont faciles à utiliser et des références pratiques sont disponibles avec une démonstration de code sur le site de démonstration. Probablement plus tard, lorsque votre site aura plus de données à traiter et que beaucoup d’informations devront être traitées dans la firebase database, vous pourrez twigr tout cadre d’access aux bases de données (ORM).

Je ne peux pas croire que personne n’a mentionné GWT

Mon moyen préféré pour des applications très simples est Apache VelocityTools (VelocityLayoutServlet) avec Velosurf ( http://velosurf.sourceforge.net ).

Pour les applications plus complexes, Spring MVC ou Struts 2.

Essayez HybridJava – c’est beaucoup plus simple qu’autre chose.

Je dirais vaadin ou guichet