Et si on repensait les ORMs ?

Depuis plus d'une décennie les ORMs accompagnent nos projets PHP. Qu'ils utilisent le pattern Active Record (Propel/Eloquent) ou Data Mapper (Doctrine) ils essaient d'apporter une interface objet à la manipulation d'une base de données SQL.

En une décennie PHP a beaucoup évolué et son utilisation dans nos projets aussi (avec une utilisation plus importante en CLI). Sur cette même période de nouvelles pratiques sont également apparues comme le Domain Driven Design ou la programmation fonctionnelle en ce moment.

Là où des choix n'étaient pas gênant au moment de leur conception, ils sont devenus de nos jours problématiques.

L'utilisation de process à vie longue comme les workers exige une gestion de la mémoire de façon stable pour éviter des crashs. Les ORMs qui gardent en mémoire les entités chargées nous délèguent donc la charge de devoir gérer la mémoire.

L'utilisation d'objets muables pour représenter les entités pose également problème en cas d'erreur dans une logique métier car il est difficilement possible de savoir quelles sont les données qui sont encore cohérentes de celles qui ne le sont plus.

Le choix que chaque objet représente une ligne en base de données nous oblige également à devoir spécifier un id dans chaque classe même s'il n'y en a pas besoin d'un point de vue métier. Par exemple pourquoi devrions nous spécifier des ids sur chaque adresse d'un utilisateur ?

Dans cette conférence nous verrons comment l'ORM Formal répond à ces problématiques grâce aux principes de conception objet issus du Domain Driven Design et à l'immuabilité poussé par la programmation fonctionnelle.

Nous verrons également les opportunités qu'ouvre cet ORM comme le choix de la persistence entre :
* SQL,
* Filesystem qui permet un prototypage rapide et une utilisation d'un filesystem "en mémoire" permettant de paralléliser des tests plus facilement
* Elasticsearch si le besoin est de retrouver des données le plus rapidement possible.

Il amène également une compatibilité à un fonctionnement asynchrone, notamment utile pour une utilisation dans des workers et indispensable pour pouvoir fonctionner avec l'Actor Model.

Comments