Le titre est racoleur comme cette illustration que j'ai volontairement floutée.
(L'originale est disponible sur google image)
Rails est un framework MVC : modele/view/controleur
La philosophie de Rails est aussi dans la re-factorisation du code, de manière à éviter d'avoir des gros contrôleurs. Ce défaut est source de toutes les difficultés : maintenance , réutilisation du code et évolution de l'application.
J'illustre mon propos par un exemple de projet qui gère un portefeuille applicatif. Ces applications sont de différentes technologies ,et on doit pouvoir filtre les applications sur leur type de technologie :
Dans une première version , jamais mis en dur dans le contrôleur les options de filtre possible.
Après modifications , j'arrive à :
Un modèle plus 'gros':
Ce modèle contient toute la logique de sélection (Select SQL)
Il ne faut pas hésiter à faire des méthodes 'find' taillées sur mesure.
Le contrôleur:
Le contrôleur est allégé pour ne contenir que la partie 'métier' du traitement. Dans cette solution , non seulement les tests 'en dur' ont disparus mais en plus l'ajout d'une nouvelle catégorie ne nécessitera aucune modification de code.
La vue est elle aussi simplifiée:
D'une manière générale, il faut éviter de mettre trop de traitement dans les vues. Cela rend l'application, très difficile à maintenir et le code inséré dans les vues est assez contraignant à écrire.
Où se trouve alors tout le traitement qui génère l'affichage de la console de bouton radio ? . Car malheureusement, il faut bien qu'a un moment donné une méthode prenne en charge :
a) Afficher toutes les options
b) Pré-selection de l'option 'cochée'.
Cette méthode va etre placée dans les 'helpers' de l'application qui prendra cette forme:
Je n'ai pas forcement le bon style d'écriture du code. Ici on fabrique le HTML utile pour les boutons radio.
Cette méthode n'est possible que parce ma liste des options était contenue dans une table.
En résumé : toujours re-factoriser son code : DRY : don't Repeat Yourself ou Duplication is Evil . Dans mon exemple la logique de la gestion des options est dans le helper et que dans lui. Le resultat donne un système qui evoluera sans modification à apporter au code.
En conclusion je me pose la question suivante : Pourquoi doit on re-factoriser dans les langages proceduraux et ne pas le faire dans les langages fonctionnels ?.
Aucun commentaire:
Enregistrer un commentaire