Comme beaucoup de développeurs, il m'est souvent arrivé de tomber sur des projets utilisant plusieurs sous projets. Exemple:
- Site développé avec un framework
- Blog sous Wordpress
- Boutique sous Prestashop
- Forum sous phpBB
Lorsqu'il faut interagir avec tout ce beau monde dans un même projet, ça peut vite finir en spaghetti. Voir pire si un de ces scripts n'a pas l'API suffisamment ouverte, il faut dupliquer du code à défaut de toucher le code du noyau. En gros parfois il faut choisir entre la lèpre (dupliquer) ou le choléra (toucher au noyau).
Dupliquer complique la maintenance. Toucher le noyau casse les mises à jours officielle et peut réduire les performances.
Autre solution, intercepter le code à l'exécution. Autant le faire avec un design éprouvé depuis des années dans d'autres langages, l'AOP (Aspect Oriented Programming)!
Problème, les solutions permettant l'interception de code avec le paradigme de l'AOP ne sont pas légion en PHP. La solution la plus fiable (c'est relatif) est l'extension PECL AOP-PHP.
Hélas ce projet n'est plus maintenu.
Alors j'ai créé PHP-AOP, une librairie Open Source fournissant une abstraction de l'AOP indépendante de l'intercepteur de code.
Ainsi je peux faire de l'AOP en me basant sur l'intercepteur de code qui me semble le plus fiable du moment, en attendant qu'une solution pérenne voit le jour.
Les projets actuels utilisant PHP-AOP seront facile à migrer vers ce nouvel intercepteur compte tenu que l'API ne change pas.
De la même façon qu'il est simple de passer de SQLight à MySQL avec un ORM (Doctrine par exemple).
Pour résumer le workflow, je créais un dossier /aop, j'y mets mes aspects (pointcuts + advices).
Un bootstrap (aop/bootstrap.php) que je place (require_once) dans chaque fichier de config des scripts avec lesquels je dois interagir.
Exemple avec les comptes utilisateurs, il faut que:
- lorsque un utilisateur s'inscrit, qu'il soit ajouté dans les scripts (soit dans mon exemple: le framework, Wordpress, Prestashop et phpBB).
- lorsqu'un compte est supprimé ou modifié, de même il faut répercuter à tous ces scripts.
- Idem pour la connexion et déconnexion.
L'AOP a rendu bien plus simple la gestion de ce style de projets qui se retrouvent inévitablement dans la main d'un développeur Web à un moment ou un autre lorsqu'on est freelance ou en Web agency.
Ca c'est pour le coté rustine ! Il y a aussi une utilisation plus conventionnelle de l'AOP qui m'a également motivé à écrire cette lib, la séparation des préoccupations transversales (cross-cutting concerns). C'est à dire séparer le code métier, du code transversal (debug, log, cache, accès utilisateurs, ...).
C'est une approche intéressante. Plus besoin de mélanger le code d'un environnement de développement et de production. La partie debug, etc (exemple le profiler de Symfony ou Laravel), n'est tout simplement pas envoyée sur le serveur de prod.
Les controllers sont épurés de tout codes liés aux systèmes pour ne laisser que le code métier, exemple :
récupérer article -> retourner la vue de l'article.
Ca va vite pour produire une version alpha d'un projet et le présenter au client, faire les refactos, etc.
A chaque validation du client, on y ajoute la partie transversale (cache, privilèges utilisateurs, ...)
En environnement de développement la mise en cache n'est tout simplement pas traité, ça log et debug à tout va, etc
Cela permet aussi de transformer le comportement de l'application pour faciliter les tests unitaires
En production (et pré-production) la gestion du cache est activée, le debug n'est pas là (pas de if(DEBUG) ...), seul les logs critiques sont implémentés pour surveiller le bon fonctionnement de l'application.
Tout ça c'est bien beau mais il n'existe pas encore d'intercepteur de code activement maintenu.
A l'époque où j'ai écris PHP-AOP la version de PHP était PHP5.4, l'extension PECL AOP-PHP fonctionnait plutôt bien avec cette version. En discutant avec l'un des auteurs de l'extension, il semblait y avoir une certaine volonté pour reprendre le développement de l'extension.
Maintenant ne faisant plus trop de PHP depuis quelques temps au profit de JavaScript / Node.js, je n'ai hélas pas eu l'occasion de développer un intercepteur de code suffisamment fiable pour être exploité sereinement en prod.
Cependant si vous vous retrouvez avec la patate chaude entre les mains, c'est à dire un projet ayant une stack vieillissante (voir bancale) sous php5.3 / php5.4, alors PHP-AOP vous sera sûrement utile pour coder proprement sans toucher au code legacy. Sûrement que cette approche plaira d'avantage à votre client, plutôt qu'aller rajouter une autre couche de code dans le code legacy.
AOP.io : Site officiel - Sur GitHub