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

J'envisage de créer mon propre site Web en utilisant Java et j'essaie de décider quel framework utiliser. Cependant, faire une recherche rapide de frameworks Java en retourne plus de 50!

Mon site Web sera juste pour mon propre plaisir de le construire au début, mais s'il devient populaire, il serait bon qu'il ait une certaine évolutivité, ou au moins puisse être en mesure de le redessiner pour cela.

Quelles sont les principales différences entre les frameworks les plus populaires? Y a-t-il des cas où l'un surpasse considérablement les autres? Par exemple, les applications d'entreprise à fort trafic par rapport aux petites applications à faible trafic. Je me demande également si certains sont beaucoup plus faciles à apprendre et à utiliser que d'autres.

Y a-t-il quelqu'un qui a l'expérience de certains de ces cadres et qui peut faire une recommandation? Le grand nombre de choix sert-il simplement d'avertissement précoce pour éviter le développement Web basé sur Java lorsque cela est possible?

J'ai beaucoup utilisé Tapestry 3 , Wicket , Echo et JSF . Je vous recommande vraiment de regarder ces derniers et de choisir celui qui vous semble le plus simple et qui correspond le mieux à la façon dont vous préférez travailler.

Parmi eux, le plus confortable pour moi de travailler était Wicket , en raison de la nature légère de la création de composants et de la simplicité de la création de modèles de page. Cela va doublement si vous utilisez votre propre code db au lieu d'Hibernate ou d'un autre framework (je n'ai jamais été complètement satisfait de Wicket Hibernate ou de Spring Integration).

Echo est génial si cela ne vous dérange pas d'é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 restreint. Ils modifient également le modèle de développement à chaque version majeure.

Tapestry 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 mec. Howard Lewis Ship est sans aucun doute assez intelligent, mais je suis déçu de leur décision d'oublier fondamentalement la rétrocompatibilité avec chaque version. Encore une fois, cependant, pour vos besoins, cela n'a peut-être pas d'importance, 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 ai un penchant pour lui, avec de grands espoirs pour son avenir. Je pense que la prochaine version (2.0) qui sera livrée en JEE6 le fera vraiment prendre son envol, avec une nouvelle syntaxe de modèle (similaire à Facelets) et un modèle de composant simplifié (composants personnalisés dans un seul fichier ... enfin).

Et, bien sûr, il existe un million de frameworks et d'outils plus petits qui ont leur propre suivi ( 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 jeter un coup d'œil à Tapestry, Wicket et JSF et de choisir celui qui vous convient le mieux. Vous en trouverez probablement un qui correspond parfaitement à votre façon de travailler très rapidement.

Mon préféré est le Spring Framework. Avec 2.5 Spring, MVC est vraiment génial, avec de nouvelles annotations, une convention sur les fonctionnalités de configuration, etc.

Si vous faites juste quelque chose de très simple, vous pouvez également essayer d'utiliser l'API Servlet standard et ne pas vous soucier d'un framework.

Je recommande le framework Wicket orienté composants . Il vous permet d'écrire votre application Web dans un ancien code Java, vous pouvez utiliser des POJO comme modèle pour tous les composants et vous n'avez pas besoin de vous amuser avec d'énormes fichiers de configuration XML.

J'avais développé avec succès une application bancaire en ligne avec Struts lorsque j'ai découvert Wicket et vu à quel point le développement d'applications Web peut être facile!

J'ai récemment commencé à utiliser le Framework Stripes . Si vous recherchez un cadre basé sur des requêtes qui est vraiment facile à utiliser, mais n'impose aucune limite à ce que vous faites, je le recommande vivement.

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

Il y a beaucoup de bons cadres là-bas même si j'ai entendu dire que wicket est également un 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 d'asp classique, c'est le premier framework web java qui me semble prometteur ....

MISE À JOUR: Tapestry 5.2 est sorti, il n'est donc pas abandonné, comme cela semblait l'être 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 message pour le refléter.

Je ne peux plus recommander Tapestry comme je le faisais auparavant. 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, chaque mise à jour majeure de la version de Tapestry a rompu la compatibilité avec les préjugés extrêmes, bien plus que ce à quoi on pourrait s'attendre. Cela semble être dû à l'incorporation de nouvelles techniques ou technologies de codage qui nécessitent des réécritures importantes.

Howard Lewis Ship (l'auteur principal de Tapestry) est certainement un brillant développeur, 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 à peu près dévoué à cela, laissant Tapestry 4 entre les mains d'autres contributeurs, qui, à mon avis, ne sont pas aussi capables que Ship. Après avoir fait le douloureux passage 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é. Je ne voudrais pas de problème avec cela si le chemin de mise à niveau n'a pas été si brutal à nouveau . Alors maintenant, notre équipe de développement est dans une position plutôt peu enviable: nous pourrions continuer à utiliser une plate-forme Web essentiellement abandonnée (Tapestry 4), faire la mise à niveau odieuse vers Tapestry 5, ou abandonner complètement Tapestry et réécrire notre application en utilisant une autre plate-forme. Aucune de ces options n'est très intéressante.

Tapestry 5 est censé être écrit de manière à réduire la probabilité de rupture de la mise à jour à partir de ce point. Un bon exemple est dans les classes de page: dans les incarnations précédentes, les classes de page descendant d'une classe de base fournie par Tapestry; les changements d'API incompatibles dans cette classe étaient à 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 au moment de l'exécution avec la "poussière de fée magique de la Tapisserie" via des annotations. Ainsi, tant que le contrat pour les annotations est maintenu, les modifications apportées à 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 voudrez peut-être jeter un coup d'œil à Vaadin . C'est un framework AJAX open source orienté UI qui, pour moi, est agréable à utiliser (je viens moi-même d'un background PHP).

Il y a une étude de cas qui compare faire la même application (c'est-à-dire deux applications avec le même ensemble de fonctionnalités) dans Icefaces et Vaadin. En un mot, il indique que le développement de l'interface utilisateur a été 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 un long moment à tester diverses solutions, pour moi, cela s'est avéré être:

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

• jQuery pour tous les trucs côté client

• Spring Security pour l'aspect sécurité

• Hibernation / JPA2

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

Un mois d'une courbe d'apprentissage extrêmement raide, mais maintenant je suis heureux.

Je voudrais également mentionner que j'étais juste un petit pas loin de sauter tout ce truc Java et d'apprendre à la place Scala / LIFT. 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 toujours un peu un hack (prouvez-moi tort par des preuves, s'il vous plaît !). 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 également entendu de bonnes choses sur Spring Framework. En général, cependant, j'ai été déçu par la plupart des frameworks Web Java que j'ai examinés (en particulier Struts).

Pour une application simple, j'envisagerais certainement d'utiliser des servlets et des JSP "bruts" et je ne me soucierais pas d'adopter un framework. Si les servlets sont bien écrits, il devrait être simple à l'avenir de porter vers un framework si nécessaire lorsque l'application devient plus complexe.

Mon choix est Wicket !!

Tous - c'est le problème ;-)

Je pense que pour vos modestes besoins, il vous suffit de coder des servlets ou de simples pages jsp que vous pouvez servir à partir du serveur Tomcat. Je ne pense pas que vous ayez besoin de tout type de cadre Web (comme des struts) pour les données personnelles de sites Web

Dire "utiliser JSF" est un peu trop simple. Lorsque vous décidez d'utiliser JSF, vous devez choisir une bibliothèque de composants en plus. 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 trop difficile à dire. Personne n'a le temps d'évaluer toutes les alternatives prometteuses, du moins dans les projets sur lesquels je travaille, car elles ne sont pas assez grandes pour faire des phases d'évaluation de trois mois. Cependant, vous devriez rechercher certains d'entre eux qui ont une communauté nombreuse et active et qui ne sont pas partis depuis un an. JSF existe depuis un certain temps, et comme il est poussé par le soleil, il le restera encore. 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 cadre 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 ces frameworks (Wicket est mon préféré) que si l'application devait ressembler davantage à une application de bureau. Mais j'essaierais d'utiliser une approche REST + AJAX plus évolutive et plus simple.

Spring MVC serait un candidat, mais depuis Spring MVC 3, il a un étrange modèle de programmation surchargé d'annotations qui n'utilise pas les avantages du typage statique. Il y a d'autres choses horribles comme les paramètres de sortie dans les méthodes combinées avec un retour habituel, il y a donc 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 de 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 les résultats.

Et n'oubliez pas que l'API Servlet avec quelques petits assistants comme FreeMarker pour la création de modèles est très puissante.

J'ai évalué pas mal de frameworks et Vaadin ( http://vaadin.com/home ) a percolé jusqu'au sommet.

Vous devriez au moins lui donner une courte é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 destinés au public) ou juste un cadre de service (comme Jersey / JAXRS) avec une boîte à outils JavaScript (pour les petits et moyens projets) .

Je recommande Seam, surtout si vous avez besoin de persévérance.

Voir quelques commentaires sur certains Frameworks d'applications Java (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 JSF avec la bibliothèque Richfaces . Les composants d'interface utilisateur Richfaces sont faciles à utiliser et des références pratiques sont disponibles avec une démonstration de code dans le site de démonstration. Probablement plus tard, lorsque votre site aura plus de données à gérer et que beaucoup d'informations devront être traitées dans la base de données, vous pourrez y brancher n'importe quel framework d'accès à la base de données (ORM).

Je ne peux pas croire que personne n'ait mentionné GWT

Mon moyen préféré pour des applications vraiment 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