Ruby on Rails : le framework MVC pour les ap­pli­ca­tions Web complexes

En 2004, l’en­tre­prise amé­ri­caine de dé­ve­lop­pe­ment Web 37signals (aujourd’hui Basecamp) a publié Basecamp, une ap­pli­ca­tion de gestion de projet incluant des fonc­tion­na­li­tés telles que des to-do listes, un ges­tion­naire de temps et un système de mes­sa­ge­rie. Une partie du programme était une ar­chi­tec­ture basique conçue par le pro­gram­meur David Hei­ne­meier Hansson, mais elle a été extraite la même année, et publiée en 2005 en tant que framework open source in­dé­pen­dant pour le Web. Son nom est devenu Ruby, et est aujourd’hui plus connu sous le nom de Ruby on Rails, que l’on abrège parfois en RoR ou sim­ple­ment Rails. Le fait que le framework, aujourd’hui géré par une équipe de plusieurs dé­ve­lop­peurs, soit devenu l’une des solutions les plus re­cher­chées pour la création de nouvelles ap­pli­ca­tions Web, était pro­ba­ble­ment difficile à imaginer à l’époque.

Depuis que Ruby on Rail a été publié sous licence MIT, le framework a continué à être développé. A cet égard, il est resté fidèle à sa phi­lo­so­phie de départ, le principe Don’t repeat yourself (« ne vous répétez pas »). Dans un projet basé sur le framework Rails, chaque in­for­ma­tion doit donc n’être dis­po­nible qu’une seule fois. Par exemple, définir les colonnes d’un tableau uni­que­ment dans la base de données est suffisant, et il n’y a pas besoin de garder cette in­for­ma­tion dans le code source ou dans un fichier de con­fi­gu­ra­tion séparé. Le module im­plé­menté Active Records lit lui-même depuis la base de données.

Le second paradigme con­cep­tuel s’intitule con­ven­tion over con­fi­gu­ra­tion (« la con­ven­tion avant la con­fi­gu­ra­tion »). Le framework RoR spécifie en effet plusieurs con­ven­tions, en par­ti­cu­lier en ce qui concerne les classes de noms. Pour un dé­ve­lop­peur, s’appuyer sur ces con­ven­tions permet de gagner un temps con­si­dé­rable. Toutefois, Ruby on Rails permet également des con­fi­gu­ra­tions al­ter­na­tives, ce qui signifie qu’il reste une grande flexi­bi­lité dans la pro­gram­ma­tion de votre ap­pli­ca­tion Web.

Au milieu des années 90, le japonais Yukihiro Matsumoto a publié le langage orienté objet Ruby. D’abord utilisé es­sen­tiel­le­ment au Japon, le langage de script s’est peu à peu établi en tant qu’al­ter­na­tive populaire aux leaders du marché tels que PHP, Python, etc. Ce succès n’est pas dû au hasard : le but de Matsumoto est de faire de Ruby un outil qui rend la pro­gram­ma­tion di­ver­tis­sante et réunit les meil­leures ca­rac­té­ris­tiques des autres langages. Il s’agit d’un langage de script in­ter­prété : le code est donc exécuté par un in­ter­prète, ce qui rend Ruby lé­gè­re­ment plus lent que les scripts compilés, mais également bien plus flexible et dynamique. Dans la mesure où il existe des in­ter­prètes spé­ci­fiques pour la plupart des systèmes d’ex­ploi­ta­tion courants, le code Ruby n’est pas dépendant d’une pla­te­forme en par­ti­cu­lier. L’une des autres ca­rac­té­ris­tiques es­sen­tielles de Ruby est sa capacité multi-pa­ra­digmes, ce qui est également le cas de C++ par exemple. L’uti­li­sa­teur n’est pas lié à un paradigme de pro­gram­ma­tion en par­ti­cu­lier. Grâce au « principe de moindre surprise », l’uti­li­sa­tion du langage de script est intuitive et ne présente pas, en principe, de com­por­te­ment inattendu. En tant que programme open source sous licence BSD, Ruby jouit d’une com­mu­nauté large et active, qui a contribué à créer de nom­breuses bi­blio­thèques de pro­grammes. La plupart d’entre elles sont soumises à la même licence et jouent un rôle majeur dans le dé­ve­lop­pe­ment de nouvelles ap­pli­ca­tions Web. Elles peuvent être ins­tal­lées, utilisées et mises à jour grâce à RubyGems. L’un de ces Gems (dont fait également partie l’API Web public de Google et Facebook), est le framework Rails.

Les en­vi­ron­ne­ments d’exécution Ruby-on-Rails sont des systèmes fermés. Ils con­tien­nent les in­ter­prètes, les bi­blio­thèques de pro­grammes né­ces­saires et les scripts res­pec­tifs. Chaque projet rail fait au­to­ma­ti­que­ment l’objet d’une structure de ré­per­toire re­grou­pant les scripts, les con­fi­gu­ra­tions, les classes, le contenu, etc. Cette approche struc­tu­relle, ainsi que la gestion in­dé­pen­dante des données et de leurs ajus­te­ments, rend la main­te­nance des ap­pli­ca­tions Web plus facile. On parle dans ce cas d’une ar­chi­tec­ture modèle-vue-con­trô­leur (MVC), dont les dif­fé­rents com­po­sants sont les suivants :

En général, les ap­pli­ca­tions Rails sont liées à des bases de données re­la­tion­nelles. Le framework Ruby a besoin de modèles pour com­mu­ni­quer avec le système de gestion de chaque base de données, ainsi que pour créer et manipuler les entrées. Ces modèles re­pré­sen­tent des classes sur des tableaux de bases de données, ainsi que des attributs in­di­vi­duels pour les colonnes ap­pro­priées. Par défaut, la couche du modèle est basée sur le framework ORM (object re­la­tion­nal mapping). Depuis Rails 3.0 il est également possible d’utiliser d’autres bi­blio­thèques ORM comme Sequel.

Les couches de vue ou de pré­sen­ta­tion ont besoin que le framework puisse accéder aux données de la couche de modèle et les vi­sua­li­ser. Pour ce faire, Ruby on Rails utilise la classe Action View, com­pa­tible avec de nombreux formats de sortie. View présente les données cor­res­pon­dantes sous forme de fichiers HTML. Les documents XML ou JSON sont utilisés pour accéder aux entrées de bases de données dis­po­nibles pour d’autres pro­grammes ou services.

Les con­trô­leurs cons­ti­tuent l’interface entre les couches de modèle et de vue. Ils exécutent les demandes entrantes grâce au na­vi­ga­teur Web, extraient les modèles concernés de la base de données, et les trans­fè­rent aux vues qui mettent la vi­sua­li­sa­tion en œuvre. En tant qu’unité centrale de contrôle de l’ap­pli­ca­tion Rails, le con­trô­leur gère aussi la mémoire cache, ou regroupe en une seule session des requêtes de dif­fé­rents clients ef­fec­tuées dans la même période de temps.

En tant que framework pour ap­pli­ca­tions Web, Ruby on Rails propose, dans sa con­fi­gu­ra­tion standard, tous les com­po­sants né­ces­saires à un dé­ve­lop­peur pour pro­gram­mer une ap­pli­ca­tion puissante. La seule condition sup­plé­men­taire est que Ruby, le ges­tion­naire de paquets RubyGems et une base de données SQL soient installés. Pour la suite, l’équipe de Rails re­com­mande la bi­blio­thèque de pro­grammes open-source écrite en langage C SQLite, qui contient un système de base de données re­la­tion­nelle. Voici les modules standards du framework Ruby on Rails :

• Action Con­trol­ler : ce module permet de créer des in­ter­faces entre les entrées de la base de données d’une part, et les pro­grammes et les uti­li­sa­teurs qui y accèdent d’autre part.

• Action View : Action View vous offre la pos­si­bi­lité de générer une vi­sua­li­sa­tion pour chaque entrée et chaque con­trô­leur. En ce qui concerne les ap­pel­la­tions, la con­ven­tion veut que chaque vue soit nommée d’après le con­trô­leur respectif.

• Active Record : il s’agit d’un module central pour la ma­ni­pu­la­tion de la base de données de votre ap­pli­ca­tion Rails. Pour créer un modèle in­di­vi­duel avec Active records, une con­fi­gu­ra­tion poussée n’est pas né­ces­saire, tant que l’on adhère aux con­ven­tions, d’ap­pel­la­tion notamment. À cette fin et grâce à son système d’écha­fau­dage, Ruby on Rails propose le meilleur outil pour créer des in­ter­faces adaptées aux quatre opé­ra­tions CRUD, qui pré­sen­tent une base de données orientée objet.

• Active Resource : ce module met en œuvre le mapping objet-re­la­tion­nel (ORM) pour les services Web REST. À l’instar d’Active Record, ce composant s’efforce de minimiser les con­fi­gu­ra­tions.

• Action Mailer : ce module permet d’envoyer et de recevoir des emails dans votre ap­pli­ca­tion Web. Pour ce faire, il est facile de créer une adresse email et un nom d’uti­li­sa­teur.

• Active Support : le module Active support contient plusieurs classes de pro­grammes d’aide utiles, et des ex­ten­sions de bi­blio­thèques standards.

• Railties : Railties est conçu pour permettre à tous les com­po­sants du framework RoR de fonc­tion­ner ensemble. Pour cette raison, chaque module a mis en œuvre son propre Railtie, par exemple pour commencer le processus d’ini­tia­li­sa­tion ou pour effectuer les con­fi­gu­ra­tions du framework. Railties est également né­ces­saire pour ajouter les modules propres à Ruby on Rails.

Il existe une blague bien connue sur les choix de langages de script :

 « Deux dé­ve­lop­peurs discutent des langages de pro­gram­ma­tion qu’ils utilisent. Le premier dit : « je travaille avec Java, et je laisse mes enfants jouer avec PHP ». Le second lui répond : « je joue avec mes enfants, et je laisse Ruby tra­vail­ler pour moi ! ».

Cette petite blague fait certes montre d’une pointe d‘exa­gé­ra­tion, mais le cœur du propos est fondé. Java, considéré comme une solution de premier choix, est souvent utilisé pour les fra­me­works dans le domaine pro­fes­sion­nel. Toutefois, pro­gram­mer avec ce langage qui ne dépend d’aucune pla­te­forme est tout sauf simple : c’est gé­né­ra­le­ment compliqué et nécessite beaucoup de temps à cause de la structure souvent complexe. En tant que langage de script, Ruby n’est donc apparenté à aucune pla­te­forme en par­ti­cu­lier. Mais en même temps, un code créé avec Ruby est plus rapide, facile à per­son­na­li­ser et moins lourd. En revanche, le langage d’in­ter­pré­ta­tion rend la vitesse des ap­pli­ca­tions dé­ve­lop­pées plus lente que les mêmes ap­pli­ca­tions dé­ve­lop­pées avec Java.

Par rapport à Java, PHP présente également des avantages im­por­tants en termes de sim­pli­cité et d’effort de dé­ve­lop­pe­ment. Dans le dé­ve­lop­pe­ment Web, il s’agit de la solution de référence par ex­cel­lence, qui est à la base, entre autres, de nombreux systèmes de gestion de contenu comme Wordpress, TYPO3 ou Joomla. Dans la mesure où PHP a été agencé de façon plutôt ar­bi­traire et qu’il n’est pas toujours orienté objet, il est parfois pénible de mettre à jour des ap­pli­ca­tions Web qui ont été dé­ve­lop­pées avec des versions plus anciennes. Ruby on Rails, au contraire, a été en­tiè­re­ment orienté objet depuis ses débuts : les ap­pli­ca­tions dé­ve­lop­pées avec des anciennes versions pré­sen­tent donc un code plus clair que les projets PHP standard.

Ruby on Rails contient un framework intégré, qui permet de tester les fonc­tion­na­li­tés de votre ap­pli­ca­tion à tout moment. Grâce à cette pos­si­bi­lité, les erreurs peuvent être décelées et corrigées dès le début. Des tech­niques de Web 2.0 telles qu’AJAX peuvent être utilisées en quelques lignes. De plus, Ruby et le framework Rails disposent d’une énorme com­mu­nauté qui ne cesse de grandir, comme en atteste le large choix d’ex­ten­sions dis­po­nibles.

La phi­lo­so­phie innovante de Rails, c’est-à-dire la recherche de la plus grande sim­pli­fi­ca­tion possible pour le dé­ve­lop­peur, que Matsumoto a mis en œuvre dès le début avec le système d’écha­fau­dage, les con­ven­tions fixes ou la structure MVC, a servi de modèles à de nombreux fra­me­works ul­té­rieurs. C’est un principe que l’on retrouve dans les fra­me­works PHP Symfony, CakePHP et Zend Framework .

Ruby on Rails offre tout ce dont a besoin un dé­ve­lop­peur pour créer des ap­pli­ca­tions Web modernes : une structure pour la création d’in­ter­faces de premier choix, une connexion facile à une base de données SQL, ainsi que la pos­si­bi­lité d’installer des tech­no­lo­gies Web telles qu’AJAX. Les principes clairs Don’t repeat yourself et Con­ven­tion over con­fi­gu­ra­tion four­nis­sent la base d’un code net et léger, facile à gérer et à per­son­na­li­ser, et qui s’écrit fa­ci­le­ment. La con­fi­gu­ra­tion ne pose par con­sé­quent aucun problème, dans la mesure où Ruby offre au pro­gram­meur toute la liberté dont il a besoin. C’est ce qui rend le framework facile à utiliser tant par des débutants que par des pro­gram­meurs confirmés, qui tra­vail­laient jusqu’alors avec d’autres langages de script. Dans les deux cas, un temps d’adap­ta­tion sera toutefois né­ces­saire. Grâce au système d‘écha­fau­dage, il est possible de réaliser ra­pi­de­ment des pro­to­types de projets Web planifiés. C’est sans doute l’un des atouts prin­ci­paux du framework Ruby. Grâce à l’en­vi­ron­ne­ment incluant des tests, il est possible de tester ré­gu­liè­re­ment l’ap­pli­ca­tion en cours de dé­ve­lop­pe­ment pour re­cher­cher d’éven­tuelles erreurs. Ruby on Rails est également équipée pour les ap­pli­ca­tions complexes. Grâce aux ex­ten­sions RubyGems, qui sont comprises dans le framework, il est possible d’ajouter fa­ci­le­ment des in­ter­faces, des bi­blio­thèques, ainsi que des fonc­tion­na­li­tés ou des options visuelles. Puisque Ruby et le framework RoR sont soumis à la licence BSD gratuite, vous ne payez que les frais d’hé­ber­ge­ment de votre projet Web. Il ne faut toutefois pas imaginer qu’aucune con­nais­sance en pro­gram­ma­tion n’est né­ces­saire pour utiliser Ruby on Rails. Le script ne s’écrit évi­dem­ment pas tout seul comme le prétend le dé­ve­lop­peur de la blague ci-dessus. En ce qui concerne la rapidité, les ap­pli­ca­tions RoR ne peuvent pas to­ta­le­ment rivaliser avec la con­cur­rence. Le code n’est pas exécuté avant que les uti­li­sa­teurs n’accèdent au contenu en question : c’est la raison pour laquelle les requêtes mettent lo­gi­que­ment un peu plus longtemps à aboutir qu’avec des lignes de code pré­com­pilé. Si vous souhaitez organiser votre ap­pli­ca­tion avec système de gestion de contenu tel que Drupal, Joomla ou WordPress, le framework Rails n’est pas né­ces­saire. Ces exemples, comme beaucoup d’autres pla­te­formes, sont basés sur PHP. Il existe toutefois des solutions CMS basées sur Ruby on Rails comme Alchemy CMS. Il est difficile de prévoir si le dé­ve­lop­pe­ment de RoR est sus­cep­tible de menacer les leaders du marché, tels que PHP, Java et Python, mais les avantages et la po­pu­la­rité crois­sante du framework Ruby parlent d’eux-mêmes.