Comparaison de Lift avec Play2
J'ai utilisé play2 auparavant avec Java. Cela ressemblait un peu à un passe-partout, surtout si vous utilisiez akka avec Java. Mais ce n'est pas la faute du cadre.
Hier, j'ai lu "Scala pour les impatients" et j'apprécie vraiment la langue.
Maintenant, j'ai regardé les deux cadres Lift 2.5 et Play 2.0.3. Je pense que l'ascenseur a une courbe d'apprentissage plus élevée et je ne pouvais pas simplement faire quelque chose avec l'ascenseur. Ce n'est pas un con pour moi. D'après ce que j'ai vu, Lift a un design très agréable et propre.
Mais pour moi, il est difficile de dire quelles sont les principales différences. Je pense que les deux cadres sont excellents.
L'approche Views First ne vous permet pas de coder dans vos modèles, mais vous devez coder dans des extraits. J'aime beaucoup ça parce que ça me semble plus organisé. Il vous permet également d'utiliser un éditeur html normal. (je n'ai pas beaucoup d'expérience, ce n'est que ma première impression)
Pour la sécurité, je ne pense pas que ce soit le travail du cadre.
Apatride/avec état: il est difficile de dire où se trouvent les principales différences. Je sais seulement que le jeu a également un état si vous utilisez des sockets Web.
Les deux cadres peuvent être compilés après avoir appuyé sur F5. J'aime beaucoup cette fonctionnalité.
Les deux cadres utilisent sbt
Lift est livré avec autorisation mais je pense qu'il y a un plugin play2 scala qui fait la même chose
Lift a un mappeur ORM pour mongoDB. Parce que je veux utiliser noSQL, cela me semble plus propre. (Encore peu d'expérience) Edit Il y a un Mappeur ORM pour scala mongodb dans play2 https://github.com/leon/play-salat
Async - Play 2 utilise Akka. Je ne sais pas ce que l'ascenseur utilise, mais ils ont aussi quelque chose de similaire.
Soulevez des navires avec le support CSRF. Play2 a un module pour CSRF mais cela ajoute un passe-partout à votre code.
L'authentification sans état semble présenter certaines failles de sécurité. Les deux cadres ont l'authentification avec état. (play2 avec état/apatride, lift avec état)
- Quelles sont les forces de chaque cadre?
Publier ceci après avoir passé une semaine ou deux avec Lift ne sert vraiment à personne. Cependant, je veux passer un peu de temps à corriger certaines erreurs et perceptions erronées.
- Pour la sécurité, je ne pense pas que ce soit le travail du cadre.
Vous vous trompez. La sécurité est le travail du cadre. Il est essentiel que la sécurité soit effectuée par défaut plutôt que de compter sur chaque développeur pour comprendre chaque vulnérabilité de sécurité et s'assurer que chaque ligne de code en tient compte.
Tout ce que nous avons à faire est de regarder ce qui est arrivé à GitHub pour comprendre que même les meilleurs codeurs utilisant une technologie bien connue peuvent faire une erreur critique.
Lift donne une couche de sécurité solide sur le dessus, donc par défaut, il n'y a pas de XSS, CSRF, etc. mais le développeur peut creuser aussi profondément qu'il le souhaite pour la requête HTTP et traiter les octets sur le câble.
- Apatride/avec état: il est difficile de dire où se trouvent les principales différences. Je sais seulement que le jeu a également un état si vous utilisez des sockets Web.
L'ascenseur indique très clairement où vous avez besoin d'un état et où vous n'en avez pas besoin. Lift peut prendre en charge les applications sans état, partiellement avec état et complètement avec état. Page par page et demande par demande, une application Lift peut être avec état ou sans état (par exemple, en Foursquare , les pages du lieu sont sans état pour les analyses des moteurs de recherche, mais avec état pour navigateurs connectés.) Pour plus d'informations sur les décisions de conception relatives à l'état, veuillez consulter Lift, State et Scaling .
- Les deux cadres utilisent sbt
Lift utilise Maven, sbt, Buildr et même Ant. Lift est indépendant de l'environnement de construction et de l'environnement de déploiement (conteneur Java EE, Netty, peu importe). Ceci est important car il facilite l'intégration de Lift avec le reste de votre environnement.
- Lift est livré avec autorisation mais je pense qu'il y a un plugin play2 scala qui fait la même chose
Lift existe depuis plus de 5 ans et a beaucoup de modules et de trucs pour ça. Le framework Web Lift (par opposition aux modules) est indépendant de la persistance, de l'authentification, etc., vous pouvez donc utiliser n'importe quoi avec Lift.
- Async - Play 2 utilise Akka. Je ne sais pas ce que l'ascenseur utilise, mais ils ont aussi quelque chose de similaire.
Lift est compatible avec Async depuis plus de 5 ans. C'est cuit dans le cadre. Le support de la comète de Lift est le meilleur de n'importe quel framework web car, entre autres, il multiplexe toutes les requêtes "Push" sur une page via une seule requête vers le serveur, ce qui évite la famine de connexion. La façon dont Lift effectue l'asynchronisation est beaucoup moins importante car l'une des principales philosophies de Lift est que nous supprimons la plomberie du développeur afin que le développeur puisse se concentrer sur la logique métier.
Mais pour ceux qui s'en soucient, Lift a les acteurs les meilleurs et les plus légers de tous les cadres en Scala-land. Nous avons été les premiers à nous séparer de la bibliothèque Scala Actor) et avons travaillé pour ouvrir la voie à différentes bibliothèques Actor qui ont permis aux acteurs Akka et ScalaZ de prospérer.
- Soulevez des navires avec le support CSRF. Play2 a un module pour CSRF mais cela ajoute un passe-partout à votre code.
Cela fait partie de l'engagement de Lift en matière de sécurité. C'est important .
- L'authentification sans état semble présenter certaines failles de sécurité. Les deux cadres ont l'authentification avec état. (play2 avec état/apatride, lift avec état)
Les applications de levage peuvent être aussi dynamiques ou apatrides que vous le souhaitez. C'est votre choix et Lift explique très clairement comment prendre la décision.
En outre, comme je l'ai souligné dans la publication Lift, State et Scaling, le développeur doit comprendre comment sérialiser l'état de manière sécurisée, évolutive et performante (car pratiquement chaque demande sur une application Web qui reconnaît des utilisateurs spécifiques est avec état) devrait être fait de manière prévisible et sécurisée par le cadre avec des remplacements raisonnables pour les développeurs.
Note d'adieu
Le jeu ressemble beaucoup à Rails: il est rapide de créer un site et il est basé sur MVC, donc beaucoup de développeurs le comprennent. Mais Play n'a pas la profondeur et l'étendue de Rails (communauté, plugins, expertise, talent, etc.) Si vous voulez un MVC rapide et facile, alors allez avec Rails = et JRuby et écrivez votre back-end en Scala (ils fonctionnent extrêmement bien ensemble.)
Lift est une bête différente. Il y a une courbe de désapprentissage importante (arrêtez de penser MVC et commencez à penser à l'expérience utilisateur qui passe d'abord à la logique métier.) Mais une fois que vous avez atteint la courbe d'apprentissage, les sites Lift sont plus sécurisés, hautement évolutifs, super interactifs et beaucoup plus faciles à maintenir au fil du temps.
Pour voir ce qui peut être fait avec Play (ça peut être cool), jetez un œil à la TypeSafe Console
Pour démarrer rapidement avec Lift, utilisez un projet de modèle .
Pour un exemple d'utilisation de Mongo avec Play, regardez Factile .
En résumé, je ne pense pas que vous vous tromperez avec Lift ou Play. Les deux sont des projets actifs, avec de bonnes communautés et un bon soutien des auteurs. Cela dépend vraiment de votre problème commercial. Si la prise en charge des outils est importante pour vous, vous voudrez peut-être envisager d'utiliser Play (il est bien pris en charge sur IntelliJ Idea).
Notez que Play, faisant partie de la pile technologique TypeSafe, aura des versions jusqu'aux dernières versions de Scala, donc si l'utilisation des fonctionnalités de Scala 2.10 sont importantes pour vous, alors vous voudrez peut-être garder Lift utilise actuellement Scala 2.9.2, ce qui est bien aussi.
Pour mon projet actuel, j'utilise lift-mapper pour ORM (c'est génial et solide comme le roc), avec Spray pour REST (ce qui est tout simplement incroyable). Cette approche évite complètement les cadres, mais cela dépend de ce que vous voulez faire. Les cadres sont souvent la voie à suivre.