Je travaille actuellement avec Groovy et Grails. Si Groovy est assez simple puisqu'il s'agit essentiellement de Java, je ne peux pas dire que je comprenne Grails. J'ai lu que Groovy est à Grails ce que Ruby est à Ruby on Rails, mais qu'est-ce que cela signifie ?
Pour répondre à votre confusion avec la métaphore (bien que la réponse ait été donnée en d'autres termes dans votre question) :
Groovy est à Grails ce que Ruby est à Ruby on Rails, mais qu'est-ce que cela signifie ?
Grails était un framework web construit sur/avec le langage de programmation Groovy pour faire la même chose pour Groovy que Rails (un framework web pour Ruby) fait pour Ruby.
Que signifie être "sur les rails" ?
La réponse à cette question se résume à l'essence même de ces frameworks web.
Ces frameworks web (Grails et Rails) sont construits sur le principe de "la convention plutôt que la configuration", ce qui signifie que l'utilisation de conventions communes pour développer des applications web peut conduire à une meilleure productivité et à des applications plus faciles à maintenir (ceci est une généralisation grossière). En définissant une convention et en vous y tenant, vous constaterez que vos applications sont faciles à générer et rapides à mettre en œuvre.
C'est ce que cela signifie pour moi d'être "sur les rails", comme un train. Lorsqu'une nouvelle ligne de train est développée, il n'est pas nécessaire de réinventer la façon dont le train se rendra d'un endroit à un autre, car une seule convention a permis de résoudre ce problème depuis des décennies : les rails. De la même manière que les rails d'une ligne de train limitent son trajet entre deux endroits, les cadres Web basés sur des conventions utilisent ces dernières pour offrir une plus grande flexibilité aux développeurs d'applications, afin qu'ils puissent se concentrer sur le problème essentiel de leur application.
L'un des principaux avantages d'une convention pour un framework web est que ce dernier peut désormais faire des suppositions sur la manière dont certaines couches de l'application s'assemblent. Dans Rails, on peut généralement supposer que si une table de base de données a un nom pluriel, la classe ActiveRecord mappée à cette table aura le nom singulier correspondant. Par conséquent, les générateurs de code Rails peuvent utiliser les informations de mappage des données pour générer du code d'accès aux données, comme les chercheurs dynamiques, les migrations, les traversées d'association paresseuses, etc. Ce code d'accès aux données dans un cadre basé sur la configuration est laborieux à coder à la main.
Plusieurs personnes ont mentionné les aspects techniques de ce qui fait des rails/grails ce qu'ils sont. Plusieurs personnes ont également mentionné que la "convention par rapport à la configuration" était le "rail" de Rails/Grails. Cela se rapproche de la vérité. Mais il ne s'agit là que d'une caractéristique de la philosophie plus large de Rails, qui est le concept de logiciel d'opinion .
Les logiciels d'opinion ne peuvent pas être décrits uniquement en termes techniques ; il s'agit d'une philosophie, d'une éthique ; une attitude . Que cela vous plaise ou non Je déteste ça. , que est ce qui est au cœur de Rails.
Voici un exemple tiré d'une année 2005. Entretien avec David Heinemeier Hansson créateur de Rails :
Rails est un logiciel d'opinion. Il évite de placer les anciens idéaux du logiciel dans une position primaire. L'un de ces idéaux est la flexibilité - la notion selon laquelle nous devrions essayer de prendre en compte autant d'approches que possible, et ne pas juger une forme de développement plutôt qu'une autre. Eh bien, Rails le fait, et je crois que c'est la raison pour laquelle il fonctionne.
Avec Rails, vous échangez la flexibilité au niveau de l'infrastructure pour gagner en flexibilité au niveau de l'application. Si vous êtes heureux de travailler en suivant le chemin d'or que j'ai intégré dans Rails, vous obtenez une immense récompense en termes de productivité qui vous permet de faire plus, plus vite et mieux au niveau de l'application.
Il y a aussi une interview ultérieure qui va plus loin explore le sujet .
Le fait d'être "sur les rails" est donc une métaphore pour désigner le fait d'être "opiniâtre", d'où son nom. Cela et le fait que "Ruby on Rails" est une allitération, ce que tout journaliste ou écrivain vous dira, est un moyen sûr d'attirer l'attention des gens.
Je pense qu'un cadre qui s'efforce d'être "semblable aux rails" fait référence à plusieurs choses :
au niveau du modèle : un ORM à modèle AR (plutôt qu'un datamapper), des migrations ou une gestion automatisée des schémas et des couches de modèle, la gestion des clés étrangères dans l'application (pas dans le schéma de la base de données, et pas non plus en utilisant des procédures stockées ou la logique pure du SGBD)
TDD encouragé : squelettes générés automatiquement pour les tests unitaires,
conventions d'appellation reliant les noms de tables de bases de données et les noms de modèles, les actions des contrôleurs et des vues et les modèles HTML
schéma simplifié de reconnaissance et de génération d'itinéraires
accent sur l'architecture REST
intégration avec les librairies ajax : RJS, prototype et scriptaculous
Rails est un cadre pour le développement d'applications web avec une base de données en arrière-plan. Je pense que le nom était à l'origine un jeu de mots. Un train peut vous emmener quelque part vraiment rapide, mais seulement là où les rails vont.
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.
