Question

Je suis tout à fait nouveau pour le développement Web Java et je voudrais choisir un bon framework Java Web pour apprendre. Je l'ai trouvé de très bons échos sur le cadre Apache Wicket et play framework. J'ai décidé d'aller pour un d'entre eux; mais je dois choisir; -)

Alors, quoi choisir et pourquoi?

EDIT

Mes besoins:

  • J'ai eu une bonne expérience dans le développement de Django, donc un cadre similaire serait formidable,
  • je besoin d'un cadre qui peut interagir avec d'autres goodies Java grand public (bibliothèques, outils ..etc) afin que je puisse profiter de ce que Java ne offre vraiment.
Était-ce utile?

La solution

Wicket et Play sont deux types de cadres très différents.

Play est un framework MVC que vous aurez probablement se sentir familier avec venant de Django. Comme Django, il offre plus que les bits de Web et fournit un cadre ORM basé JPA, outils échafaudages et probablement beaucoup plus (je n'ai pas l'expérience pratique avec elle). Ils ont un grand tutoriel sur leur site, et vous verrez probablement des similitudes Django là.

Wicket est un cadre axé sur des composants (comme JSF et tapisserie) et se concentre fortement sur la conception orientée objet. Il est également MVC, en soi, mais les pages sont généralement construites en composant autonomes et des composants réutilisables (vue et le contrôleur, Modèles) connectables. Ces composants peuvent être prolongés par héritage standard et la composition et le balisage est très nettement séparés de code et facilement modifiés.

Wicket peut gérer callbacks d'événements et état automatiquement, de sorte que vous ne faites pas Vous de penser urls à tous, peu importe la complexité de votre page est. Un exemple rapide pour un bouton cliquable qui va un loin quand il est cliqué (très utile):

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

Je tiens à souligner que vous ne devez pas utiliser l'état côté serveur, et qu'il est tout à fait possible d'utiliser Wicket comme un framework MVC « normal » si vous voulez (et oui, il est facile d'obtenir de jolies urls) .

Le projet Wicket se concentre uniquement sur le framework web de base et il n'y a pas supplémentaires « » subtilités telles que le soutien ORM spécial ou d'un échafaudage. Je suis personnellement d'accord avec la philosophie du projet Wicket, mais pour les nouveaux développeurs venir au cadre, à faire des trucs de « simples », comme une table triables et paginable peut être un redoutable bits en tant que composants pré-construits sont un peu rares. L'apprentissage et la courbe de productivité pour Wicket peut être un peu raide, mais la hausse est qu'une fois que vous avez fait des composants (et « comportements » - plus histoire) qui correspondent à vos besoins, ils sont extrêmement réutilisables.

Bien que j'aime personnellement Wicket, j'ai une intuition que vous serez probablement mieux avec Play. Votre question indique que vous voulez un « Django » avec accès à Java libs, et dans ce cas, je pense Play (ou un autre Java MVC) est le choix sûr. D'autre part, vous avez peut-être été en utilisant Django parce que vous ne savez pas comment Wicket est incroyablement puissant. ;.) Si vous donnez un peu plus d'informations sur votre projet, nous serons en mesure de donner une réponse plus qualifiée

En tant que nœud latéral: Comme Le jeu est pas très grand public (au moins pour l'instant), je voudrais aussi considérer Grails qui a un fort soutien commercial et encore plus out-of-the-box modules.

Autres conseils

Play! est conçu pour être à l'aise pour les développeurs provenant de langages de script comme Python et PHP. Il fournit ses propres scripts système de construction et de gestion, un peu comme Rails ou Django Would. outils de construction et des infrastructures existantes (comme les dépôts Maven couramment utilisés pour la gestion des dépendances en Java terre) ne sera pas intégrer bien avec le jeu.

Wicket sera plus confortable pour les développeurs à venir du développement de bureau en Java. Il ne fournit pas d'outillage spécial, il sera plus facile à intégrer dans un outil de construction spécifique si vous avez une préférence (et il existe de nombreux outils de construction fournissant des choses comme la récupération de dépendance automatisé disponible dans l'écosystème Java.)

Donc, il est tout à fait une certaine différence entre les deux options :) Si vous pouvez comprendre que l'expérience serait avantageux pour vous plus, la décision devrait être assez claire de là.

Si votre système est uniquement pour le niveau Web, Play! cadre est très approprié. But, si vos modèles de données ne sont pas seulement pour le web, exported as REST by Spring with CXF peut-être, et consommés par GWT ou d'autres services Web, et que vous voulez vous assurer que les états cohérents avec niveau Web, Wicket (avec Spring / mise en veille prolongée) est un bon choix.

Quelque chose que je ne me sens pas bien dans Play! est le mécanisme de mise en cache. Vous devez nommer manuellement / insérer / extraire / Invalider / cache purge. Cela rendra toute l'architecture sujette aux erreurs. Alors que le printemps avec wicket / JPA (veille prolongée) / ehcache (ou d'autres fournisseurs), vous pouvez définir la mise en cache cohérente / dao couche pour la couche supérieure (Web / REST ...), qui ne sera pas imposer des incohérences de l'État.

Un autre avantage avec portillon incorporé, il a un support intégré AJAX soutenu par Java. Bien que ces états du AJAX sont maintenus dans le côté serveur (et peut-être un peu lent), si vous ne voulez pas apprendre JavaScript, vous pouvez toujours construire un « pas si mauvais » page AJAX.

Avec Play! Si vous ne connaissez pas JS, et ne veulent pas apprendre, ne veulent pas manipuler DOMs encombrants, vous ne pouvez construire un site « moyenne ». OTOH, si vous êtes qualifiés avec JS / jQuery, vous pouvez choisir Play! .

J'utilise PLay! beaucoup et ont utilisé Wicket pour un peu d'évaluation. Mon expérience est que vous devez écrire un code plus beaucoup pour obtenir le même travail avec Wicket. Vous avez plus « indirection » avec Wicket. Personnellement, je préfère le code qui a aussi peu que « cérémonie » possible et facile à suivre.

Le Play! architectes sont également Scala l'ajout du support pour jouer !, que je pense est une excellente idée, car Scala est entièrement interopérable avec le code Java et les bibliothèques mais beaucoup plus avancés puis Java.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top