Pourquoi devrais-je utiliser Scala / Lift sur Java / Spring?
Je sais que cette question est un peu ouverte, mais je considère Scala/Lift comme une alternative à Java/Spring et je me demande quels sont les véritables avantages de Scala/Lift. De mon point de vue et de mon expérience, Java Annotations and Spring minimise réellement la quantité de codage que vous devez effectuer pour une application. Scala/Lift améliore-t-il cela?
Supposons que nous sommes également à l'aise dans Scala et Java) et ignorons les différences de langue (énormes), sauf en ce qui concerne Spring ou Lift.
Spring et Lift sont presque diamétralement opposés en termes de maturité et d'objectifs.
- Le printemps a environ cinq ans de plus que l'ascenseur
- Lift est monolithique et cible uniquement le Web. Spring est modulaire et cible à la fois les applications Web et "classiques".
- Spring supporte une pléthore de Java EE; Lift ignore ce genre de choses
Dans une phrase, Spring est un poids lourd et Lift est léger. Avec suffisamment de détermination et de ressources, vous pouvez renverser la situation, mais vous auriez besoin d'un lot des deux.
Voici les différences concrètes qui me sont restées gravées dans l’esprit après avoir travaillé avec les deux cadres. Ce n'est pas une liste exhaustive, que je ne peux en aucun cas compiler. Juste ce qui m'a semblé le plus intéressant ...
Voir la philosophie
Lift encourage à placer du contenu de vue dans des méthodes d’extrait ou d’action. Le code des extraits sera parsemé d’éléments de formulaire générés par programme,
<div>s,<p>s, etc.C’est puissant et utile, d’autant plus que Scala possède un mode XML intégré au niveau de la langue. On peut écrire du XML inline au sein de méthodes Scala, y compris des liaisons de variables entre accolades Cela peut être agréable pour des services XML très simples ou des maquettes de services - vous pouvez créer une suite d’actions de réponse HTTP dans un fichier extrêmement concis, sans modèles ni configuration standard. L'inconvénient est la complexité. Allez, il y a soit une séparation floue des préoccupations entre vue et logique, soit aucune séparation.
En revanche, l’utilisation régulière de Spring pour les applications Web impose une forte séparation entre la vue et tout le reste. Je pense que Spring prend en charge plusieurs moteurs de gabarit, mais je n’ai utilisé JSP que dans des applications sérieuses. Faire une conception "fuzzy MVC" inspirée de Lift avec JSP serait une folie. C'est une bonne chose pour les grands projets, où le temps de simplement lire et comprendre peut être accablant.
Choix du mappeur relationnel-objet
L'ORM intégré de l'ascenseur est "Mapper". Il existe une alternative à venir appelée "Record", mais je pense qu'elle est toujours considérée comme pré-alpha. Le livre LiftWeb contient des sections sur l'utilisation de Mapper et de JPA.
La fonctionnalité CRUDify de l'ascenseur, cool, ne fonctionne qu'avec Mapper (et non JPA).
Bien entendu, Spring prend en charge une panoplie de technologies de base de données standard et/ou matures . La Parole opérative il y a "supports". Théoriquement, vous pouvez utiliser n'importe quel Java ORM avec Lift, puisque vous pouvez appeler du code arbitraire Java depuis Scala. Mais Lift ne prend vraiment en charge que Mapper et En outre, travailler avec nontrivial Java code in Scala n’est pas aussi transparent que l’on pourrait le souhaiter; utiliser un Java ORM, vous vous retrouverez probablement en utilisant les deux collections Java et Scala partout dans le monde) ou en convertissant toutes les collections dans et hors du Java composants.
Configuration
Les applications Lift sont presque entièrement configurées via une méthode "Boot" de classe. En d’autres termes, la configuration s’effectue par le biais du code Scala). C’est parfait pour les projets comportant de brèves configurations et lorsque la personne chargée de la configuration est à même d’éditer Scala.
Spring est assez flexible en termes de configuration. De nombreuses options de conf peuvent être gérées soit par la configuration XML, soit par des annotations.
Documentation
La documentation de Lift est jeune. Les documents du printemps sont assez mûrs. Il n'y a pas de concours.
Comme les documents de Spring sont déjà bien organisés et faciles à trouver, je passerai en revue les documents que j'ai trouvés pour Lift. Il existe essentiellement 4 sources de documentation Lift: le LiftWeb Book , le API Docs , le LiftWeb le groupe Google et " Mise en route ". Il existe également une belle suite d’exemples de code, mais je ne les appellerais pas "documentation" en soi.
Les documents de l'API sont incomplets. Le livre LiftWeb a été publié sur des arbres, mais il est également disponible gratuitement en ligne. C'est vraiment utile, même si son style résolument didactique m'a parfois irrité. C'est un peu long sur le tutoriel et court sur le contrat. Spring a un manuel approprié, ce qui manque à Lift.
Mais Lift a une belle série d’exemples. Si vous êtes à l'aise pour lire le code Lift et l'exemple de code (et que vous savez Scala déjà bien)), vous pouvez résoudre le problème assez rapidement.
Les deux cadres sont convaincants. Il existe une large gamme d'applications où vous pouvez choisir l'un ou l'autre et bien faire.
Je vous recommanderais de vérifier le cadre de jeu. Il contient des idées très intéressantes et soutient le développement en Java et Scala
Juste pour le fun. Et pour apprendre de nouvelles approches de programmation.
J'ai fortement étudié l'utilisation de Lift pour un projet Web récent, sans être un grand fan de Spring MVC. Je n'ai pas utilisé les dernières versions, mais les versions précédentes de Spring MVC vous ont fait franchir de nombreux obstacles pour faire fonctionner une application Web. J'étais presque vendu sur Lift jusqu'à ce que je voie que Lift peut être très dépendant d'une session et nécessite des "sessions collantes" pour fonctionner correctement. Extrait de http://exploring.liftweb.net/master/index-9.html#sec:Session-Management
Jusqu'à ce qu'il existe une technologie de réplication de session standard, vous pouvez toujours mettre en cluster votre application en utilisant une "session collante". Cela signifie que toutes les demandes relatives à une session HTTP doivent être traitées par le même nœud de cluster
Ainsi, une fois qu'une session est requise, l'utilisateur doit être associé à ce nœud. Cela crée un besoin d'équilibrage de charge intelligent et affecte la mise à l'échelle, ce qui a empêché Lift d'être une solution dans mon cas. J'ai fini par choisir http://www.playframework.org/ et j'ai été très heureux. Le jeu a été stable et fiable jusqu'à présent et très facile à utiliser.
Je n'a pas viens à Lift et Scala à partir d'un Java arrière-plan, donc ce n'est pas de l'expérience personnelle, mais je sachez que de nombreux développeurs Lift considèrent que Scala est un langage beaucoup plus concis et efficace que Java.
Je déteste jeter complètement votre monde pour une boucle. Mais vous pouvez utiliser Scala, Java, Lift, Spring dans une seule application et que ce ne soit pas un problème.
Élargir vos connaissances est toujours une entreprise louable :) Je viens de commencer à apprendre Scala, cela affecte ma façon d'écrire Java normal _ et je peux dire que cela a été très bénéfique jusqu'à présent.
Mais le principal problème est que nous ne pouvons pas comparer le printemps avec l'ascenseur. Lift est essentiellement utilisé comme cadre d’interface utilisateur et Spring comme cadre DI.
Si vous développez une application Web qui dispose de suffisamment d’arrière-plan, vous pouvez utiliser l’ascenseur.
mais si votre application web en développement comporte une série de back-end et que vous avez absolument besoin de passer au printemps.
À mon humble avis, l'imagination est ce qui compte.
Considérons que vous voulez écrire une application. Si vous êtes un bon développeur, l'application devrait déjà être intégrée à votre esprit. La prochaine étape consiste à découvrir comment cela fonctionne avec le code. Pour ce faire, vous devez transmettre l'application imaginée à travers une fonction qui la traduit en application réelle. Cette fonction est un langage de programmation. Alors
Real app = programming language (imagined app)
Le choix de la langue est donc important. Donc, le cadre. Il y a une tonne de personnes intelligentes ici qui vous conseilleront sur ce qu'il faut choisir, mais au final, le langage/cadre qui traduit le mieux votre imagination devrait être votre choix. Alors prototype avec les deux et fais ton choix.
Quant à moi, j'apprends lentement Scala et Lift and love it.