Au-delà de MVC(2)

Le design pattern MVC est très à la mode dans le monde PHP. Beaucoup d'articles le présentent, mais peu en font comprendre l'essence. Ils passent généralement à côté de l'essentiel : la séparation des préoccupations.

MVC : la séparation des préoccupations

En effet, l'intérêt d'opter pour MVC ne se résume pas à la possibilité de produire différentes vues d'un même modèle (sortie html, pdf, wml, etc) : qui utilise véritablement cette possibilité ? Son intérêt n'est pas non plus de permettre une meilleure coopération entre programmeurs et graphistes grâce aux templates ; ces langages, type Smarty, qui seraient à la porté d'apprentissage de tout designer, sans doute trop stupide pour comprendre PHP. En fait, PHP convient très bien aux designers : appels de fonction, boucles, tableaux et variables sont quasiment les seules notions de PHP utiles pour coder des interfaces graphiques !

MVC est généralement présenté dans sa seconde version (passant sous silence l'inclusion d'un Front Controller à la version initale) comme un modèle en 3 couches (Direction|PHP de décembre 2004 par exemple) 

• La couche de modèle contient la logique métier de l'application.
• La couche de vue assure la représentation graphique et les fonctionnalités ergonomiques.
• Le contrôleur assure la connexion entre les deux et le traitement des requêtes des utilisateurs.

Mais les choses deviennent plus floues et contradictoires d'un auteur à l'autre lorsqu'il s'agit de définir précisément ce que contiennent ces couches. Par exemple, certains définissent le modèle comme les données uniquement, d'autres comme les données + le mécanisme d'accès aux données (DAO) + la logique métier. En caricaturant, on pourrait considérer le modèle comme étant la base de données, la vue comme étant le HTML envoyé au navigateur et le contrôleur tout le reste, c'est à dire tout le code !

En fait, MVC est populaire parce que c'est une très bonne illustration d'une philosophie du développement : la séparation des préoccupations (Separation of Concerns). La plupart des bonnes pratiques et des design patterns ne font que mettre en application ce principe : séparer les différentes responsabilités dans des portions de code le plus indépendantes possibles.

MVC n'est donc pas un pattern en couches, mais un principe de séparation des responsbilités au seins de composants. Un même composant peut être à la fois un modèle et une vue : un data bag, par exemple, est un modèle qu'une vue HTML présentera à l'utilisateur, mais c'est aussi une vue de la base de donnée produite par un contrôleur, le DAO. Ce principe simple ne semble généralement pas compris. A quoi bon affirmer qu'il ne faut pas mettre de code HTML dans le modèle (php|architect de mai 2003), si c'est pour le remplacer par des objets de type colonne gauche, colonne droite, comme dans Drupal ? La programmation est, depuis son origine, l'art de séparer les responsabilités. Que ce soit la programmation orientée aspect ou objet ou les catalogues de design pattern, le but est toujours le même : la programmation modulaire. C'est un exercice difficle car si on en comprend aisémemnt le principe, on ne sait pas le formaliser.