[java] Dois-je utiliser Vaadin Framework



Answers

Après presque un an et demi à développer une application GWT pas si énorme, en utilisant toutes les meilleures pratiques que j'ai apprises des dernières E / S de Google comme MVP, EventBus, CommandPattern, etc. Je dis ça du fond du cœur: après avoir passé des jours à essayer Pour que les choses se passent comme mon équipe et mon client le souhaitaient techniquement et visuellement, même après la sortie d'UiBinder, Vaadin est venu comme une lumière au bout du tunnel.

Après avoir écrit près d'un millier d'actions standard pour le modèle de commande, un autre millier de présentateurs et vues et un autre millier de gestionnaires d'événements, etc. Ne pas avoir à gérer près de 75% de ces classes tout en conservant une bonne approche pattern (appfoundation add-on) un peu de frais généraux de réseau est acceptable. Avec Vaadin, prêt à l'emploi, vous obtenez de bons widgets, pagination, liaison de données, mise en page sans faille. Tout ça pour quoi? Un peu plus de consommation de mémoire côté serveur.

Je pense que je peux dire que c'est acceptable parce que je ne construis pas le prochain Facebook ou quelque chose. Je peux toujours gérer des milliers d'utilisateurs simultanés par serveur moyen tout en maintenant des allers-retours à faible latence.

Avec Vaadin, je peux construire une jolie application avec presque la moitié des lignes de code et l'application semble toujours plus complète. :-)

!! MISE À JOUR 23 février 2011: Je ne peux pas souligner comment il faut être conscient des limites de chaque cadre. Vaadin n'est pas différent. Il faut savoir que Vaadin résout toute forme de HTML ou JavaScript. En outre, le HTML résultant est très lourd et vous devriez vous occuper des changements d'état de l'histoire vous-même. Alors, soyez conscient de ces frais généraux lorsque vous construisez votre projet.

Question

J'ai juste essayé de jouer avec Vaadin Framework et il me semble très facile à utiliser. Plus ce que j'aime dans son framework, c'est qu'il est construit sur Google Web Toolkit (GWT) .

Que pensez-vous, devrais-je continuer à utiliser ce cadre ou il vaut mieux rester avec GWT?




Nous avons regardé Wicket où je travaille mais nous avons trouvé au lieu de 9 000 fichiers, nous pourrions en avoir plus de 30 000. Nous avons près de 1000 écrans avec notre application de services financiers de base et bien que Wicket soit superbe, il est extrêmement difficile de convertir notre code Struts 1.3 en Wicket. Notre architecte a fait un projet de POC et seulement 3 écrans ont ajouté plusieurs centaines de classes (beaucoup sont réutilisables). Il est également difficile de prototyper un écran avec Wicket puisque votre code HTML doit correspondre au code Java et vice-versa.

Vaadin semble prometteur mais ce sera difficile à vendre pour l'équipe.

PS Peu importe la qualité d'un framework, personne ne l'apprendra s'il n'est pas utilisé dans l'industrie. Wicket a été autour pendant un certain temps encore très peu d'entreprises l'utilisent. La plupart des développeurs avec qui je parle sont concernés par l'apprentissage d'un nouveau cadre qui est inutile sur un CV.

L'élément clé est que Vaadin utilise un design de type Swing et que j'ai commencé en Java en utilisant Swing.




J'ai commencé avec Vaadin il y a seulement deux jours et j'ai pu construire une petite application CRUD sur OSGi avec modularité, liaison de données, services OSGi pour la persistance. Une chose vraiment sympa est que mon interface utilisateur complète n'est que de 118 lignes de code et supporte des opérations CRUD complètes pour une structure de beans java simple.

Il est également agréable que Vaadin fonctionne parfaitement dans OSGi. C'est déjà un paquet et j'ai trouvé un petit pont de Neil Bartlet qui rend vaadin extrêmement facile à utiliser dans OSGi.

Voir la liste des tâches Vaadin Exemple




Pour construire de bonnes interfaces utilisateur, je dirais que ce serait le chemin à parcourir. De plus, c'est très bien documenté.




Le discours habituel sur Vaadin concerne le jeu de widgets et s'inquiète de la communication aller-retour entre le client et le serveur.

Mais à mon avis, cela néglige l'aspect le plus significatif (peut-être révolutionnaire) de Vaadin: il élimine complètement la tâche de concevoir et d'implémenter la communication client-serveur habituellement requise pour les applications AJAX (le "A" et le "X" dans AJAX) .

Avec Vaadin, vous pouvez complètement oublier les DTO (objets de transfert de données), les problèmes de sécurité basés sur le protocole, les exceptions de chargement paresseux d'Hibernate, etc.

Dans un certain sens, vous écrivez simplement une ancienne application de bureau Java Swing, mais vous utilisez une autre boîte à outils de Swing.




Il y avait des «préoccupations» à propos de Wicket en utilisant des sessions pour gérer les états des composants et l'évolutivité similaire aux arguments sur Vaadin et le traitement côté serveur. J'ai appris au cours des 10 dernières années que la communauté Java est généralement mal sur la façon de mesurer le potentiel d'un cadre web (entre autres choses). De JSF à Grails, il faut habituellement quelques centaines de Go de mémoire et au moins une douzaine de fichiers jar open source avec des fonctionnalités chevauchantes et inefficaces pour lancer une application de production. Regardez autour de vous et vous verrez que la plupart des sociétés d'hébergement Web n'offrent pas une option Java pratique en raison du chemin erratique que les technologies Java ont pris pour les frameworks web. GWT 2.1 est toujours difficile à utiliser en raison de la vitesse de compilation et il devient juste sérieux avec MVP et les tables de données qui auraient dû être là depuis le début. J'aime Wicket mais Vaadin semble prometteur ... mais sachant comment les frameworks Java vont, je suis sûr qu'ils se tireront dans le pied à un moment donné mais je doute que ce soit à cause du lourd traitement côté serveur.







J'utilise aussi Vaadin. Bien que l'application ne soit pas grande, ce que j'ai vraiment aimé de l'expérience, c'est que l'API était cohérente, généralement bien documentée et que je développais avec un nouvel outil, je pouvais lancer des choses pour un client très exigeant, ou dans certains cas, de meilleurs délais que les outils que j'ai utilisés auparavant.

Très peu de problèmes. Le seul en ce moment est le client insiste sur l'utilisation d'IE 7 (ne pas demander) et certains de l'eye candy ne fonctionne pas totalement à 100% dans un composant addon (graphique).

BTW Je ne travaille pas pour Vaadin non plus :-)




Je pensais que Wicket était la voie à suivre, jusqu'à ce que j'ai essayé de le faire fonctionner efficacement et a commencé une dépression (blague). Ensuite, je suis passé à GWT, qui avait l'air génial, mais il y a tellement de code à écrire pour la chaudière et la documentation n'est pas terrible ... -> La lumière est venue du Vaadin: simple, opérationnel, pas de bugs jusqu'à présent ... !!!




Related