En effet, la couche d’abstraction de base de Dolibarr est bien plus performante que la plupart des ORM du marché (qui change tous les 5 ans), la ou Dolibarr a besoin de pérennité pour les 20 ans à venir).
Par exemple, la plupart des ORM renvoient le code erreur de la base de donné en cas d’erreur donc un code qui varie selon la base, la ou celui de Dolibarr renvoie un code commun. La couche ORM de Dolibarr est plus facile à appréhender puisque rien à faire de particulier. Il permet d’avoir un processus de migration qui garantie à chaque version un migration sans perte de donnée, et sans que le développeur ait à se soucier de quoi que ce soit, ni en terme de type ou version de base de donnée ni en terme de codage (ce ne sont que des exemples, il y a des tas d’autres raisons déjà exposés à mainte reprise). Il garanti aussi que le développeur se soucie de la problématique de performance en pensant sa requête « par rapport aux données et au besoin » plutôt qu’en codant de manière « scolaire » en aveugle sans se soucier de l’organisation des données (ce qui n’est bien que sur le papier ou pour un TP d’école), mais qui donne de très mauvais résultats dans le cycle de vie d’un projet.
Les ORM avaient le vent en poupe dans les années 90 voire 2000 (j’en ai implémenté une dizaine), mais nous sommes en 2021 et l’air et plutôt au « nocode » et l’architecture « module builder » rend déjà obsolète le besoin d’un ORM externe qui n’apporterait rien de plus à Dolibarr (hormis tous les inconvénients et régressions cités par rapport à l’ORM natif actuel qui ne nécessite aucune maintenance, aucune mise à jour, aucune dépendance et remplit 100% des besoins).
Le question du framework MVC n’est pas nouvelle non plus. Le framework Dolibarr natif s’avère ultra productif en maintenance grâce à son approche MVC par séparation du contrôleur et de la présentation par simple commentaire (par opposition à une séparation par fichier ou par config), et de part son utilisation du moteur de template natif PHP, le plus puissant connu dans le monde PHP (les experiences d’utilisation d’autres moteurs de templates faites par le passé ayant démontré qu’en pratique, la qualité et quantité et maintenabilité du code produit n’était pas aussi bonne). Le framework natif continue d’ailleurs de creuser le faussé en terme de productivité par rapport à d’autres lorsqu’il est couplé aux capacités « no-code (but can code if you need) » apportés par Module Builder, ce qui est la direction actuelle.
Si une initiative se lance de faire un fork pour ajouter un ORM à Dolibarr ou utiliser un autre framework que celui natif de Dolibarr, elle est la bienvenue, et l’asso Dolibarr pourra communiquer dessus (comme ce fut déjà fait par le passé sur d’autres fork), c’est la force du libre.
Je ne pense pas que cela divise les force, au contraire, cela évite que les directions se contredisent et évite que certains ralentissent d’autres. Une direction suivi par 500 développeurs vaut mieux que 2 directions différentes suivi par 1000 développeurs. Ce n’est donc pas forcément une mauvaise chose.
J’ai toutefois la conviction (et l’histoire des nombreux essais précédent ont confirmés cette conviction) que cela n’ira pas loin car, un projet qui priorise des actions qui n’apportent rien à un projet, si ce n’est réduire la productivité de codage pour les développeurs non aguerris (je ne parle pas de théorie, ou de principe de « bonne pratique sur le papier » mais d’expérience du terrain ayant déjà expérimenté ces théories), ni rien aux utilisateurs, se trompe de priorité et provoque souvent sa mort prématurée. Cela reste toutefois bienvenue car l’histoire peut toujours contredire tout le monde.
Bref, sans pragmatisme, Dolibarr ne serait pas la où il est aujourd’hui (l’application serait même morte il y a de nombreuses années), aussi il n’y a, à ce jour, pas de volonté d’abandonner ce pragmatisme et de faire des choix déjà expérimentés par le passé et qui, dans la vrai vie, se sont avéré apporteur de plus de problème que d’avantages. Aussi la direction actuelle est plutôt de continuer de profiter de la pérennité et la bonne productivité du framework actuel, tout en l’améliorant avec module builder ou en le perfectionnant via des micro-librairies plutôt que par des changements trop contraignants ou contre-productif.
perso je pense pouvoir dégager une à deux journées par semaine
