Framework PHP MVC : pourquoi s'en passer

Beaucoup plus populaire que les conteneurs implémentant l'inversion de contrôle, les frameworks MVC (Model-View-Controller ou Modèle-Vue-Contrôleur) en PHP sont légion. Ils participent de cette attente irrationnelle du monde PHP envers la programmation orientée objet et son corollaire, le framework. Seul Rasmus Lerdorf semble percevoir le comique de la situation avec son no-framework PHP MVC framework. Avant de vous décidez de démarrer votre prochain projet avec un tel framework, considérez d'abord les inconvénients suivants :

• Une application moins performante. Les diverses couches d'abstraction et la panoplie impressionnante de composants accompagnant tout framework en font un mécanisme lourd, consommant beaucoup de ressources matérielles. La mise en production peut alors s'accompagner de l'achat, en urgence, d'un système de cache performant pour remédier aux performance déplorables. Rappelons-nous des difficultés de lancement du GéoPortail ou plus récemment les débuts difficiles du comparateur de prix des carburants du Minefi.
• Coût de développement accrus. La complexité du framework induit des salaires plus élevés pour les développeurs spécialisés en raison de leur rareté ou des frais de formation (ou de perte de productivité) pour les autres développeurs. Ajoutez les frais de formation à un nouveau langage de script si le framework s'appuie sur un moteur de template style Smarty, très à la mode chez les développeurs PHP. Ces moteurs n'ont aucune utilité (si ce n'est de complexifier le développement) comme le montre bien l'article PHP for designers de Matt Mullenweg (co-fondateur et développeur principal de WordPress). Seule compte la séparation des préoccupations.
• Une application bridée. Une autre conséquence de la complexité d'un framework est la difficulté de l'étendre ou de l'adapter à ses besoins particuliers.
• Une application ne répondant pas aux besoins des utilisateurs. La plupart des framework font des choix radicaux en termes de conception grévant les fonctionnalités de l'application. L'exemple le plus simple : l'URL rewriting. L'URL d'une page est généralement de la forme http://my.web.com/module/action/params pour invoquer l'action action du module module. Aussi lorsque l'on souhaite créer un site web dont les URLs représentent l'architecture fonctionnelle du site, cela s'avère très compliqué ! Ainsi au lieu d'avoir l'URL http://www.numabilis.com/services/realisation_de_sites_web on a quelque chose comme http://www.numabilis.com/article/view/id/35. Le module de réécriture fourni est généralement insuffisant : les sections Services et Réalisations étant toutes deux constituées d'articles, la réécriture ne permet pas de distingués les articles de ces deux sections ! Comme souvent les couches techniques imposent des contraintes fortes sur le fonctionnel.

Les frameworks PHP, dans leur très grande majorité, souffrent d'une trop grande complexité. Ils singent le monde Java (voir les implémentations PHP de Struts : Phrame, PhpMVC ou Studs) en faisant du tout objet avec force renfort de template engine et de mod_rewrite.

Par conséquent, sauf si vous êtes chef de projet dans une grosse structure, dont le poste n'est justifié que par votre capacité à résoudre les problèmes que vous avez vous même créés, vous devriez vous passer d'un tel framework.

Veni Vidi Wiki (dessin de Brad Fitzpatrick)