site - spring java




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

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 pour les frameworks Java revient à plus de 50 choix!

Mon site Web sera pour mon propre plaisir de le construire au début, mais s'il devient populaire, il serait bon pour lui d'avoir une certaine évolutivité, ou au moins d'être capable de refonte pour cela.

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

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


Après un long moment de tester diverses solutions, pour moi, il s'est avéré être:

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

  • jQuery pour tous les trucs côté client

  • Spring Security pour l'aspect sécurité

  • Hibernate / JPA2

  • Jetée pour les continuations (comète)

Un mois d'une courbe d'apprentissage extraordinairement raide, mais maintenant je suis heureux.

Je voudrais également mentionner que j'étais juste un peu loin de sauter tout ce truc de 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 (prouvez-moi faux par des preuves, pleeease !). 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


Dire "utiliser JSF" est un peu simple. Lorsque vous décidez d'utiliser JSF, vous devez choisir une bibliothèque de composants. 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 Facelets pour vos vues?

À mon avis, c'est difficile à dire. Personne n'a le temps d'évaluer toutes les alternatives prometteuses, au 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 regarder autour de vous qui a une grande communauté active et qui n'est pas partie depuis un an. JSF est là depuis un certain temps, et comme il est poussé par le soleil, il sera encore plus disponible. Je ne peux pas dire si c'est le meilleur choix, mais ce sera un bon choix.


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é!


J'ai aussi entendu de bonnes choses à propos du 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'utiliserais certainement des servlets et des JSP "raw" et je ne m'inquiéterais pas d'adopter un framework. Si les servlets sont bien écrits, il devrait être simple dans le futur de porter un framework si nécessaire lorsque l'application devient de plus en plus complexe.


J'ai utilisé assez JSF Tapestry 3 , Wicket , Echo et JSF . Je vous recommande vraiment de regarder ceux-ci et de choisir celui qui vous semble le plus facile, et le plus proche de la façon dont vous préférez travailler.

Parmi eux, le plus confortable pour moi était Wicket , en raison de la nature légère de la construction de composants et de la simplicité de la mise en 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 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 une niche assez étroite. Ils changent le modèle de développement avec chaque version majeure aussi bien qu'il semble.

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 mené principalement par un mec. Howard Lewis Ship est sans aucun doute très intelligent, mais je suis déçu de leur décision d'oublier la rétrocompatibilité avec chaque version. Encore une fois, cependant, pour vos besoins, cela n'a pas d'importance, et j'ai toujours trouvé que les produits Tapestry étaient agréables à utiliser.

JSF est sorti depuis des années et a toujours l'impression d'avoir été construit par un gars de Struts 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 l'amènera vraiment avec une nouvelle syntaxe de template (similaire à Facelets) et un modèle de composant simplifié (composants personnalisés dans seulement 1 fichier ... enfin).

Et, bien sûr, il y a un million de cadres et d'outils plus petits qui se suivent ( Velocity pour les besoins de base, JSPs brutes, Struts, etc.). Je préfère généralement les cadres orientés composants moi-même, cependant.

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.



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


Je pense que pour vos besoins modestes, vous avez juste besoin de coder des servlets ou de simples pages jsp que vous pouvez utiliser depuis le serveur Tomcat. Je ne pense pas que vous ayez besoin d'un framework web (comme des entretoises) pour vos données personnelles


Je recommande le cadre Wicket orienté composant. Il vous permet d'écrire votre application web dans du vieux code Java, vous pouvez utiliser des POJO comme modèle pour tous les composants et vous n'avez pas besoin de manipuler d'énormes fichiers de configuration XML.

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


MISE À JOUR: Tapestry 5.2 est sorti, donc il n'est pas abandonné, comme il semblait auparavant l'être. 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. Tapisserie 5 semble être une amélioration significative, mais mon problème principal avec Tapestry n'est pas avec la plate-forme elle-même; c'est avec les gens derrière.

Historiquement, chaque mise à jour de version majeure de Tapestry a rompu la compatibilité ascendante avec des préjugés extrêmes, beaucoup 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 significatives.

Howard Lewis Ship (l'auteur principal de Tapestry) est certainement un brillant développeur, mais je ne peux pas dire que je m'occupe 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 se consacra à peu près à cela, laissant Tapestry 4 entre les mains d'autres contributeurs, qui ne me semblent pas aussi capables que Ship. Après avoir fait le passage douloureux de Tapisserie 3 à Tapisserie 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 n'aurais pas de problème avec cela si le chemin de mise à niveau n'était pas si brutal à nouveau . Alors maintenant notre équipe de développement est dans la position peu enviable: nous pourrions continuer à utiliser une plateforme web essentiellement abandonnée (Tapestry 4), faire la mise à niveau de Tapestry 5, abandonner entièrement Tapestry et réécrire notre application en utilisant une autre plateforme. Aucune de ces options n'est très attrayante.

La tapisserie 5 est censée être écrite 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 pages: dans les incarnations précédentes, les classes de pages descendaient d'une classe de base fournie par Tapestry; Les changements d'API incompatibles dans cette classe ont été la cause 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 "Magie Tapestry fairy dust" via des annotations. Donc, tant que le contrat pour les annotations est maintenu, les modifications apportées à Tapestry n'affecteront pas vos classes de pages.

Si c'est le cas, alors écrire une nouvelle application en utilisant Tapestry 5 pourrait bien tourner. Mais personnellement, je n'ai pas envie de remettre ma main sur le brûleur.


Mon choix est Wicket !!


Mon choix serait Wicket (pour les grands projets et une base d'utilisateurs prévisible), GWT (pour les grands projets qui sont principalement publics) ou juste un cadre de service (comme Jersey / JAXRS) avec une boîte à outils JavaScript (pour les projets petits à moyens) .


Pour une interface graphique rapide et sophistiquée, vous pouvez utiliser la bibliothèque JSF avec Richfaces . Les composants de l'interface utilisateur de Richfaces sont faciles à utiliser et des références pratiques sont disponibles avec la démonstration du code sur le site de démonstration. Probablement plus tard, lorsque votre site a plus de données à gérer et beaucoup d'informations doivent être traitées dans la base de données, vous pouvez brancher n'importe quel cadre d'accès à la base de données (ORM) avec lui.


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 devait ressembler plus à une application de bureau. Mais j'essaierais d'utiliser une approche REST + AJAX plus évolutive et simple.

Spring MVC serait un candidat, mais depuis Spring MVC 3 il a un modèle de programmation surchargé d'annotation étrange qui n'utilise pas les avantages du typage statique. Il ya d'autres choses laides comme les paramètres 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 aussi tendance à réinventer la roue et vous aurez plus à configurer par rapport aux autres frameworks. Je ne peux pas vraiment recommander Spring MVC mais il a 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 les résultats.

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



Disclamer: Je travaille à Vaadin (anciennement IT Mill)

Si vous faites quelque chose de RIA, vous pourriez vouloir regarder Vaadin . C'est un framework AJAX open source orienté UI qui, pour moi, est agréable à utiliser (je viens d'un fond PHP moi-même).

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 était considérablement plus rapide.

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





rich-internet-application