53 votes

Quelles sont les principales différences entre Play Framework 1.0 et 2.0 ?

Avec la sortie récente de Play Framework 2.0, j'aimerais savoir si quelqu'un peut résumer, d'un point de vue de haut niveau, les principales différences entre Play Framework 1 et 2.

J'en ai déjà compilé quelques-uns (play 1.0 -> play 2.0) :

  • Moteur de gabarit : Pages Groovy -> Modèles Scala
  • Persistance : Hibernate -> Ebean
  • Support linguistique : Java -> Scala, Java
  • Compilation dynamique : injection de code d'octet -> compilation dynamique via SBT
  • Système de construction : n/a -> SBT
  • Extensibilité : Modules, Plugins -> Sous-projets, Plugins, plugin SBT

Quoi d'autre ? Akka ?

44voto

opensas Points 13527

Voici ma liste, bien sûr, avec quelques doublons

  • rompt la rétrocompatibilité (il s'agit d'une réécriture à partir de zéro)

  • noyau programmé en scala vs java (il faut apprendre le scala pour collaborer)

  • scala pour les modèles (mais un travail est en cours sur les modèles groovy en tant que module, pour faciliter la migration), vous devez donc spécifier le type de chaque paramètre

  • sbt console au lieu de python scripts

  • sbt pour résoudre les dépendances au lieu de la solution intégrée (commande play dependencies)

  • la disponibilité des modules, il faudra évidemment un certain temps pour les migrer tous...

  • pour java, il privilégie ebean à la place d'hibernate (mais vous pourrez utiliser hibernate)

  • pour scala, livré avec anorm (mais vous pourrez utiliser d'autres bibliothèques)

  • plus modulaire, plus facile de choisir d'autres composants

  • plus de sécurité de type - les vues et même les routes sont vérifiées au moment de la compilation

  • meilleure performance

  • le support de typesafe, il fait partie de pile sécurisée

  • moins de magie, moins de génération de bytecode et de trucs similaires

  • plus standard, (les projets de jeu sont juste des projets sbt standard)

  • API de contrôleur différente (plus verbeuse, IMHO), vous pouvez comparer une contrôleur simple play 1.x crud avec un jeu similaire 2.0 un

  • scala est un citoyen de première classe, mais java est également supporté (a une API native pour chacun d'eux).

  • la recompilation à chaud est plus lente (elle est encore en version bêta, espérons qu'ils la résolvent)

  • le support IDE de scala n'est pas aussi mature que celui de java (mais il évolue bien)

  • support asynchrone délégué à akka

  • mieux préparé pour différents types de sources de données, comme les dbs nosql

Pour plus d'informations, consultez le site page de lecture 2.0 (traduction en espagnol disponible) aquí ) et le Documentation RC1

Quoi qu'il en soit, je pense que la principale différence est que play 1.x a essayé de construire sa propre pile tout en échappant à j2ee, maintenant ils font partie d'une pile nouvelle et alternative, basée sur scala, akka, sbt et avec le soutien d'une société comme typesafe....

18voto

niels Points 4445

Je trouve le point suivant important. Certains sont des pros, d'autres des contras. Vous devez voir par vous-mêmes quelle version vous préférez.

  • Le noyau est écrit en Scala, donc si vous n'êtes pas un développeur Scala, vous ne pouvez pas facilement corriger un bug par vous-même. C'était une force de la version 1.2. De plus, si la documentation n'est pas très bonne, vous êtes perdu. Dans play 1.2, vous pouvez simplement regarder dans le code. Avec Eclipse, vous aviez un IDE pour rechercher facilement des références. Je ne suis pas sûr qu'il existe un IDE comparable pour Scala. J'ai entendu dire qu'eclipse et intellij fonctionnent bien avec, mais je n'ai pas d'expérience personnelle.

  • Les composants sont plus souplement couplés dans la version 2.0. Dans la version 2.0, vous pouvez facilement choisir votre moteur de modèle ou votre couche de persistance préférés. En 1.2, il était plus difficile de choisir autre chose que JPA pour la persistance.

  • Scala est désormais un citoyen de première classe, ce qui vous laisse le choix d'écrire votre application en Scala ou en Java.

  • Les dépendances à d'autres frameworks sont plus élevées. Par exemple, ils ont maintenant besoin de Scala et d'Akka. Les deux sont agréables, mais complexes. Vous pouvez donc rencontrer de gros problèmes en cas d'erreur dans l'un de ces frameworks. Dans la version 1.2, je ne vois un tel risque que pour Hibernate.

  • "Tout" est maintenant sans danger pour le type et peut être vérifié par le compilateur.

  • Le passage de Python à SBT implique que vous ayez besoin de beaucoup plus de mémoire sur votre machine de développement. Je veux dire que le compilateur Scala nécessite au moins 512 Mo de RAM. Cela peut être un problème sur un serveur de construction continue.

Bien sûr, il y a beaucoup de petits détails comme le mentionne Codemwnci.

13voto

Codemwnci Points 28817

Votre liste est un très bon début. Ma liste est similaire avec quelques extras.

  • Les modèles sont passés de Groovy à Scala.
  • Scala devient un citoyen de première classe, plutôt qu'un module d'extension facultatif.
  • Une plus grande attention portée à la sécurité des types, notamment dans les modèles.
  • Python à SBT
  • Hibernation vers Ebean
  • Akka pour compléter les fonctionnalités asynchrones de Play 1.x, plutôt qu'Akka en tant que module.
  • Anorm disponible dans le noyau (plutôt que dans le plugin scala)
  • Amélioration des performances en production grâce à des éléments moins dynamiques et plus compilés.
  • Intégré dans la pile TypeSafe

Il y a des doublons entre nos listes, comme vous pouvez vous y attendre. Il convient également de noter que cette liste date de novembre 2011, alors que le jeu 2 est toujours en version bêta.

10voto

Shrulik Points 121

Il y a de très bonnes réponses ici, je voulais juste ajouter quelques petits points et fournir des détails qui sont devenus plus clairs avec le temps.

Reportage dans le navigateur : Play 2 signale les erreurs dans les fichiers Javascript (à l'aide du compilateur de fermeture de Google) et CSS dans le navigateur, et pas seulement dans les fichiers Java/Scala. C'est vraiment cool.

Déploiement en tant que WAR : Jeu 2 n'est pas encore officiellement supportent le déploiement ou l'exportation en tant que WAR. A plug-in Il existe un logiciel qui est censé fournir un tel support, mais il est en version bêta et présente quelques problèmes connus. La prise en charge complète de toutes les fonctionnalités de Play 2 n'est pas vraiment possible sans les conteneurs Servlets 3.1, ce qui prendra au moins une demi-année, probablement plus.

Plug-ins : Pour l'instant, il y en a encore beaucoup d'autres pour le jeu 1, si vous dépendez d'un plug-in, assurez-vous qu'il existe aussi pour le jeu 2.

Support IDE : IntelliJ 12 devrait venir avec un support intégré pour play 2. Vous pouvez déjà obtenir le PAE (je n'ai plus de liens hypertextes autorisés, vous devrez donc chercher sur Google).

Avis subjectif : J'ai l'impression que Play 2 a sacrifié une certaine simplicité au profit d'une prise en charge de fonctionnalités plus avancées et d'une sécurité de type plus complète. Je ne dis pas que Play 2 est difficile ou non intuitif, mais il l'est moins que Play 1.

Play 1 était un framework web pour les développeurs web par les développeurs web. Play 2 est un framework web tourné vers l'avenir pour les développeurs web par les développeurs web.

Pour dire qu'il y a eu un léger changement d'orientation, la facilité d'utilisation n'est plus l'objectif principal, mais l'un des deux objectifs principaux. Ce n'est bien sûr que mon opinion et je n'en sais que très peu.

6voto

Vous trouverez un autre point de vue sur le sujet dans l'article de blog suivant : http://blog.awfbeat.com/post/22314115684/impressions-of-play-framework-1-2-4-vs-2-0

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X