Je dois dire que je ne suis pas du tout d'accord avec la réponse de Dan LaRocque.
L'ascenseur n'est pas monolithique. Il est composé d'éléments discrets. Il n'ignore pas les éléments J / EE, il prend en charge des éléments tels que JNDI, JTA, JPA, etc. Le fait que vous ne soyez pas obligé d'utiliser ces éléments de J / EE est une indication forte de la conception modulaire de Lift.
- La philosophie de la vue de Lift est de «laisser le développeur décider». Lift propose un mécanisme de modèle qui n'autorise aucun code logique dans la vue, un mécanisme de vue basé sur l'exécution de code Scala et des littéraux XML de Scala, et un mécanisme de vue basé sur Scalate . Si vous choisissez le mécanisme de création de modèles XML, vous choisissez la part de balisage, le cas échéant, dans votre logique métier. La séparation des vues de Lift est plus forte que tout ce que Spring a à offrir, car vous ne pouvez exprimer aucune logique métier dans les modèles XML de Lift.
- La philosophie de Lift's Object ↔ Persistence est de «laisser le développeur décider». Lift a Mapper qui est un mappeur relationnel d'objet de style ActiveRecord. Il fait le travail pour les petits projets. Support de levage JPA. Lift a une abstraction Record qui prend en charge la navette d'objets dans et hors des bases de données relationnelles, dans et hors des magasins NoSQL (Lift inclut la prise en charge native de CouchDB et MongoDB, mais les couches d'adaptateur sont quelques centaines de lignes de code, donc si vous voulez Cassandra ou autre chose, ce n'est pas beaucoup de travail pour l'obtenir.) Fondamentalement, Lift the Web Framework n'a aucune dépendance sur la façon dont les objets sont matérialisés dans une session. En outre, les cycles de session et de demande sont ouverts de sorte que l'insertion de hooks de transaction dans le cycle de demande / réponse est simple.
- La philosophie de Lift est que "l'équipe serveur doit connaître une langue et non plusieurs langues". Cela signifie que la configuration se fait via Scala. Cela signifie que nous n'avons pas eu à implémenter 40% des constructions de langage Java dans la syntaxe XML pour créer des options de configuration flexibles. Cela signifie que la syntaxe du compilateur et le type vérifient les données de configuration afin que vous n'obteniez aucune analyse XML étrange ou des données incorrectes au moment de l'exécution. Cela signifie que vous n'avez pas besoin d'EDI qui comprennent les particularités des annotations que vous utilisez en fonction de la bibliothèque que vous utilisez.
- Oui, la documentation de Lift n'est pas son point fort.
Cela dit, permettez-moi de parler de la philosophie de conception de Lift.
J'ai écrit le manifeste Web Framework avant de commencer à écrire Lift. Dans une large mesure, et dans une plus grande mesure que pour tout autre framework Web que je connaisse, Lift atteint ces objectifs.
Lift en son cœur cherche à abstraction du cycle de requête / réponse HTTP plutôt que de placer des wrappers d'objets autour de la requête HTTP. Au niveau pratique, cela signifie que la plupart des actions qu'un utilisateur peut entreprendre (soumission d'éléments de formulaire, exécution d'Ajax, etc.) sont représentées par un GUID dans le navigateur et une fonction sur le serveur. Lorsque le GUID est présenté dans le cadre d'une requête HTTP, la fonction est appliquée (appelée) avec les paramètres fournis. Comme les GUID sont difficiles à prévoir et spécifiques à la session, les attaques de relecture et de nombreuses attaques de falsification de paramètres sont beaucoup plus difficiles avec Lift que la plupart des autres frameworks Web, y compris Spring. Cela signifie également que les développeurs sont plus productifs car ils se concentrent sur les actions de l'utilisateur et la logique métier associée aux actions de l'utilisateur plutôt que sur la plomberie de l'emballage et du déballage d'une requête HTTP.
ajaxButton("Accept", () => {request.accept.save;
SetHtml("acceptrejectspan", <span/>}) ++
ajaxButton("Reject", () => {request.reject.save;
SetHtml("acceptrejectspan", <span/>})
C'est si simple. Parce que le friendRequest est dans la portée lorsque la fonction est créée, la fonction se ferme sur la portée ... il n'est pas nécessaire d'exposer la clé primaire de la demande d'ami ou de faire autre chose ... définissez simplement le texte du bouton (il peut être localisé ou il peut être extrait d'un modèle XHTML ou il peut être extrait d'un modèle localisé) et la fonction à exécuter lorsque le bouton est enfoncé. Lift s'occupe d'attribuer le GUID, de configurer l'appel Ajax (via jQuery ou YUI, et oui, vous pouvez ajouter votre propre bibliothèque JavaScript préférée), de faire des tentatives automatiques avec des back-offs, d'éviter le manque de connexion en mettant en file d'attente les requêtes Ajax, etc.
Ainsi, une grande différence entre Lift et Spring est que la philosophie de Lift du GUID associé à la fonction présente le double avantage d'une sécurité bien meilleure et d'une bien meilleure productivité des développeurs. L'association GUID -> Function s'est avérée très durable ... la même construction fonctionne pour les formes normales, ajax, comète, assistants multi-pages, etc.
La prochaine pièce maîtresse de Lift consiste à conserver les abstractions de haut niveau le plus longtemps possible. Du côté de la génération de page, cela signifie construire la page en tant qu'éléments XHTML et conserver la page au format XHTML juste avant de diffuser la réponse. Les avantages sont la résistance aux erreurs de script intersite, la possibilité de déplacer les balises CSS vers l'en-tête et les scripts vers le bas de la page après la composition de la page, et la possibilité de réécrire la page en fonction du navigateur cible. Du côté de l'entrée, les URL peuvent être réécrites pour extraire les paramètres (à la fois les paramètres de requête et de chemin) de manière sécurisée. Par exemple, voici comment définir le service d'une requête REST:
serve {
case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
}
En utilisant la correspondance de modèle intégrée de Scala, nous faisons correspondre une demande entrante, extrayons la troisième partie du chemin et obtenons l'utilisateur qui correspond à cette valeur, et même appliquons des vérifications de contrôle d'accès (la session ou la demande en cours a-t-elle les autorisations pour accéder à Fiche utilisateur). Ainsi, au moment où l'instance User atteint la logique de l'application, elle est vérifiée.
Avec ces deux pièces maîtresses, Lift a un énorme avantage en termes de sécurité. Pour vous donner une idée de l'ampleur de la sécurité de Lift qui ne gêne pas les fonctionnalités, Rasmus Lerdorg qui a fait de la sécurité pour Yahoo! avait ceci à dire à propos de FourSquare (l'un des sites poster-enfants Lift):
Quatre étoiles à @foursquare - 1er site depuis un moment, j'ai bien regardé qui n'avait pas un seul problème de sécurité (que j'ai pu trouver) - http://twitter.com/rasmus/status/5929904263
À l'époque, FourSquare avait un ingénieur travaillant sur le code (non pas que @harryh ne soit pas un super-génie) et son objectif principal était de réécrire la version PHP de FourSquare tout en faisant face au doublement du trafic hebdomadaire.
La dernière partie de la stratégie de sécurité de Lift est SiteMap. Il s'agit d'un système de contrôle d'accès, de navigation sur le site et de menu unifié. Le développeur définit les règles de contrôle d'accès pour chaque page à l'aide du code Scala (par exemple If(User.loggedIn _)ou If(User.superUser _)) et ces règles de contrôle d'accès sont appliquées avant le début de tout rendu de page. Cela ressemble beaucoup à Spring Security, sauf qu'il est intégré dès le début du projet et que les règles de contrôle d'accès sont unifiées avec le reste de l'application, vous n'avez donc pas besoin de processus de mise à jour des règles de sécurité en XML lorsque les URL change ou les méthodes qui calculent le changement de contrôle d'accès.
Pour résumer jusqu'à présent, la philosophie de conception de Lift vous offre les avantages du contrôle d'accès intégré, la résistance aux 10 principales vulnérabilités de sécurité de l'OWASP, une bien meilleure prise en charge d'Ajax et une productivité des développeurs beaucoup plus élevée que Spring.
Mais Lift vous offre également le meilleur support Comet de tous les frameworks Web. C'est pourquoi Novell a choisi Lift pour alimenter son produit Pulse et voici ce que Novell a à dire à propos de Lift:
Lift est le type de framework Web qui vous permet en tant que développeur de vous concentrer sur une vue d'ensemble. Une frappe forte et expressive et des fonctionnalités de niveau supérieur telles que la prise en charge Comet intégrée vous permettent de vous concentrer sur l'innovation plutôt que sur la plomberie. La création d'une application Web riche en temps réel telle que Novell Pulse nécessite un cadre doté de la puissance de Lift sous les couvertures.
Donc, Lift n'est pas juste un autre framework MVC me-too. C'est un cadre qui repose sur des principes de conception fondamentaux qui ont très bien mûri. C'est un framework qui offre le double avantage de la sécurité et de la productivité des développeurs. Lift est un framework qui est construit en couches et donne au développeur les bons choix en fonction de ses besoins ... des choix pour la génération de vues, des choix pour la persistance, etc.
Scala et Lift offrent aux développeurs une bien meilleure expérience que le mélange de XML, d'annotations et d'autres expressions idiomatiques qui composent Spring.