CPU ⬜ Carré Petit Utile

Extrait de l'émission CPU release Ex0187 : Ruby.

On entend souvent parler de framework en MVC, une structure d'architecture logicielle qui a été popularisé dans la création de sites web avec Ruby on Rails. Alors qu'est-ce que le fameux MVC, qui est devenu un standard industriel de fait en développement web ?
MVC veut dire Modèle, Vue, Contrôleur, ou Model View Controller si vous vous la pétez in english at work parce que ça fait professional. Et en gros, un framework MVC incite un développeur à structurer le code métier qu'il va créer, chaque objet qu'il va manipuler sera décrit dans trois composantes primaires, avec des responsabilités différentes, généralement ventilés dans au moins 3 fichiers de code source différents :

• Tout part du Modèle, qui est en général basé sur une table dans la base de données, donc chaque instance représente un enregistrement et chaque propriété de son objet est rattachée à une valeur de la table.
• La Vue est la représentation graphique de ce modèle, bien souvent calquée sur une représentation en liste, en lecture instance unique et en édition de cette instance. Dans le web, chacune de ces représentations est souvent associée à un template pour construire sa page web.
• Le Contrôleur est celui qui récupère les interactions de l'utilisateur et en fonction du contexte, va associer la requête au modèle et la vue correspondante.

Officiellement, le concept MVC est apparu en 1979 au Xerox Park à Palo Alto, théorisé par le chercheur norvégien Trygve Reenskaug et mis en application dans le langage SmallTalk. Ce qui est un peu logique : Ce concept est conçu pour une interface graphique, et derrière à la programmation objet.
Proposer d'organiser le code selon un moule de projet est une révolution dans le développement logiciel ; et cette révolution est aussi importante que l'écriture de tests de non-régression ou de versionnement de fichiers. Cette proposition permet de mieux travailler en équipe, de faciliter la transmission entre ses membres et de s'y retrouver plus vite entre différents projets basés sur un même framework.

Mais en fait, ce découpage et ses automations existaient assez primitivement dès les années 1970s dans des outils d'usines logiciels des gros systèmes industriels, où les bases de données géraient directement la sortie vers les terminaux textes, et récupéraient les interactions.

À la différence que le pattern MVC est lié à la programmation objet en classes. Le code métier en MVC est principalement construit en tant que classes héritées : on a des prototypes pour les classes Modèles, Vues et Contrôleurs. On peut aussi avoir des classes périphériques autour de ces trois classes comme du code événementiel, des utilitaires, les modifications de structure de modèle, des fonctions shell, une éventuelle administration. En général ces classes sont accessoires, voire auto-générées par les utilitaires de code.

Une des pratiques poussées est la Convention Over Configuration, c'est à dire que le framework incite le plus possible un développeur à utiliser le même nom dans une filiation MVC, et à réduire le nombre de décisions à prendre.
Et comme le Modèle est le plus important, son nom de classe va souvent dicter celui de son fichier, et ceux de sa Vue et de son Contrôleur. À chacun sa responsabilité dans le même type de données, et les API seront bien gardées. D'ailleurs, sur cette industrialisation du code, de nombreux frameworks MVC passent par un méta-langage de configuration pour décrire le schéma de la base de données, et de là, générer automatiquement le code pour le modèle. Les classes Modèles sont donc étroitement liées à un ORM (Object-relational mapping), qui vont faire abstraction du langage natif de la base de données, souvent en SQL, pour que le développeur n'aie qu'un seul langage de programmation à apprendre. Avec des inconvénients sur la performance des requêtes, beaucoup de fonctionnalités SQL qui sont gommées pouvant simplifier le code ou encore les particularités des moteurs de bases de données qui sont oubliées, inaccessibles voire parfois complètement tordues par le framework qui tente de les plier à sa logique.

Parmi les bonnes pratiques, les développeurs sont notamment incités à produire le contrôleur le plus maigre possible, le limitant qu'au routage, et à déporter le plus de logique vers le modèle, ou une des classes associées au modèle.

L'inconvénient est souvent dans son implémentation, parfois mal comprise. Et comme tous les frameworks, il peut être tordu par des développeurs qui n'osent pas trop en sortir, rendant l'architecture instable.

Autre problème, une architecture MVC a pour base la base de données. Et donc soit le framework est lié à un seul moteur de base de données, souvent MySQL/MariaDB, soit à un triptyque comme SQLite, MySQL et PostGres ce qui est fréquent avec un ORM. Mais comme l'ORM masque le moteur et le langage SQL, l'ORM rabote les possibilités au plus petit dénominateur commun… donc au plus primitif des moteur SQL. Ce qui veut souvent dire que des fonctions avancées comme les procédures stockées, les schémas ou les moteurs de recherche full text de PostGreSQL doivent être ré-écrits logiciellement dans le code métier car SQLite ne les connaît pas.
Autre chose, on a surtout parlé de moteur SQL, donc de RMDBS, de bases de données relationnelles, ce qui veut dire que les moteurs NoSQL ou basés sur des moteurs de recherche comme Elastic sont… ignorés.

Autre problème, l'architecture MVC fonctionne parfaitement dans un logiciel local sans trop de problème de gestion d'accès, mais il n'est pas spécialement adapté au web, sur la gestion de l'adressage des URL, des verbes d'ordres et des codes de réponses HTTP et la gestion du contrôle d'accès en amont de l'accès contrôleur… ou trop imparfaitement. Il est ainsi très fréquent que la gestion d'identification et de droit d'accès soit liés à un contrôleur, et qu'en cas de tentative d'accès à une page à accès restreint, ben des frameworks répondent par des statuts HTTP incorrects : souvent une 302 pour une redirection d'URL suivie d'une 200, pour renvoyer sur le contrôleur qui gère l'identification. Alors que retourner directement la page avec un statut 401 ou 403 qui correspondent au message d'erreur accès interdit serait nettement plus logique. On a souvent ce genre de frictions entre bonnes pratiques contradictoires, et ce n'est pas forcément la plus appropriée qui l'a emporté.

Heureusement, l'architecture MVC a connu de nombreuses évolutions, qui reprennent le principe d'un modèle de donnée, mais des interactions ou des concepts différents : les MVC hiérarchiques, les MVVM (Model View View Model), et j'en passe, une poule n'y retrouverait pas ses petits.

Si on devrait résumer, le concept d'architecture MVC est intéressant car il structure la pensée du développeur, tend à une qualité industrielle, aide celui qui reprend le projet, donne de bonnes pratiques et minimifie le nombre de décisions à prendre sur cette structure, mais il peut vite handicaper. Comme pour tout concept de développement et framework, il faut donc l'utiliser quand vraiment il est approprié.

Texte : Da Scritch
Illustration : Une représentation du MVC, CC-By-NC-SA statnice.dqd.cz