#Barcamp : L’organisation du code dans Rails
De nombreuses fonctionnalités sont disponibles pour bien organiser son code dans un projet Ruby on Rails, nous allons en aborder certains et comprendre quel est le rôle de chacun.
Concerns & modules
Dans Rails il existe des répertoires « concerns » dans les modèles et les controllers. Cela va nous permettre de mieux organiser notre code et d’éviter parfois de dupliquer des lignes. Un concern est un « module » et non une classe, il faut s’en servir et regrouper cela par fonctionnalité, et non comme un simple endroit ou stocker des méthodes diverses et variées. Petit zoom sur ces deux termes :
Concerns : quand nos modèles partagent une information (un sujet/thème/fonctionnalité) on place cette information dans un concern. Ex: sur un site, des commentaires peuvent être ajoutés/affichés depuis un article, un produit, et cela concerne (oO) aussi la table utilisateur. On va donc créer un module commentaire dans un concerns. Si dans mon model utilisateur, commentaire, produit, article je fais un « validates mon_champ » ou un « has_many mon_truc » je vais placer tout cela également au même endroit dans un concern.
Module : Un module fournit des méthodes qui seront utilisées dans plusieurs classes. C’est différent d’une classe : une classe est un objet, un module est une fonction. On peut instancier une classe, pas un module. On peut faire de l’héritage avec une classe, pas avec un module. Un module peut s’inclure dans un autre module ou dans une classe (include MonConcern en haut du fichier)
Les classes abstraites
Du fait que les modèles héritent d’Active Record, mettre en commun des méthodes d’instance entre deux modèles via une classe abstraite nécessite une configuration dans cette dernière.
On indiquera ainsi : self.abstract_class = true. La classe abstraire hérite d’Active Record : class Produit < ActiveRecord::Base. Les autres classes héritent de la classe abstraite.
Ruby ne supporte pas l’héritage multiple, ce qui peut être problématique. Il existe d’autres solutions pour pallier ce problème, tels que les mixins ou les interfaces.
Rails supporte les relations polymorphiques entre modèles Active Record : c’est le Multiple Table Inheritance.
Équilibre entre vues, partials et helpers
On hésite souvent sur la manière de suivre le pattern MVC en arrivant dans les vues. Les index sont particulièrement l’endroit d’opérer des boucles contenant des requêtes, des conditions, qui ne semble pas pouvoir être réalisées ailleurs.
Les partials et les helpers peuvent servir le même but : factoriser du code dans une vue devenant trop longue ou nécessitant de la récursivité. La différence réside dans le langage dominant de l’un et l’autre :
Les partials sont l’endroit tout indiqué pour écrire du HTML. On peut y utiliser quelques conditions et boucles tant que l’objectif servi est de la présentation.
Les helpers sont l’endroit désigné pour écrire du ruby. Une fonction doit enfermer de la logique, comme des conditions, des requêtes, et retourner quelque chose qui est inséré dans la vue. Ce n’est pas l’endroit pour construire des éléments du DOM.
Deux sites entrent plus dans le détails, en français et en anglais.
Originally published at Sois-net.