31,029
edits
Langages et normes: Difference between revisions
m
→Design patterns et programmation objet
| Line 439: | Line 439: | ||
-> Pour les développements Dolibarr, il est recommandé d'utiliser le mode de liaison '''Active Record''' qui offre les avantages d'un modèle proche du métier sans en avoir la complexité et sans trop masquer non plus la technique. C'est dans ce mode que le développement, la compréhension du code et la maintenance technique et/ou fonctionnelle semble la plus productive (ceci est toutefois un éternel débat entre les puristes et les pragmatiques, débat dans lequel personne ne peut vraiment avoir raison, car tout dépend des objectifs à atteindre). | -> Pour les développements Dolibarr, il est recommandé d'utiliser le mode de liaison '''Active Record''' qui offre les avantages d'un modèle proche du métier sans en avoir la complexité et sans trop masquer non plus la technique. C'est dans ce mode que le développement, la compréhension du code et la maintenance technique et/ou fonctionnelle semble la plus productive (ceci est toutefois un éternel débat entre les puristes et les pragmatiques, débat dans lequel personne ne peut vraiment avoir raison, car tout dépend des objectifs à atteindre). | ||
=== Design Pattern d'Interface Graphique === | |||
Il existe plusieurs design pattern pour les interfaces utilisateurs (MVC, MVP, MVVM). | |||
Beaucoup confonde ce design pattern avec celui consistant à utiliser un framework de templates. C'est sans rapport. Un framework de template (voir point précédent) n'est en lien qu'avec la partie "V" de ces modèles. | |||
-> Dolibarr utilise le Design Pattern MVC. La partie M est matérialisée par une classe DAO contenant les méthode CRUD (Create-Read-Update-Delete) d'accès à la table. | |||
Beaucoup de frameworks ont fait le choix de mettre la partie de code C (Controller) et la partie de code du V (vue) dans des fichiers, voir même répertoires séparés. La maintenance semble plus aisé sur la papier, en pratique, il faut sans arrêt jonglé entre n fichiers, le C étant fortement lié au V. Aussi dans Dolibarr, la séparation est faite par une simple section de commentaire. La partie de code C (Controller) est donc le code qui se trouve sont la balise | |||
<pre> | |||
/* | |||
* Actions | |||
*/ | |||
</pre> | |||
Elle est suivi par la partie de code V (Vue), bien séparé du C par la balise | |||
<pre> | |||
/* | |||
* View | |||
*/ | |||
</pre> | |||
Ce mode de séparation a eu un effet neutre sur les nouveaux développement mais a permis de réduire très sérieusement le temps requis pour la maintenance et correction de bugs aussi, il n'est pas envisagé de basculer vers un autre type de séparation. Ce qui est important dans le pattern MVC étant qu'il y a toujours séparation entre le C et le V (à ne pas confondre avec la séparation du code pour alimenter la données d'une Vue et pour la formater, ceci relevant du Design Pattern de Vue). | |||
=== Design Pattern de Vue - Présentation === | |||
Il existe des frameworks spécialisés dans le Design Pattern de Vue, la partie qui consiste à formater l'écran vue par l'utilisateur. | |||
Les vieilles versions de Dolibarr utilisaient Smarty. Ce framework est une surcouche à un Framework, déjà très puissant de formatage d'écran nommé PHP. Les bénéfices étant très inférieurs aux inconvénients, il a été abandonné au profit du PHP qui reste le plus simple, le plus universel des frameworks de présentation. Son seul défaut est qu'il ne peut garantir les écarts d'un développeur qui irait intégrer une logique sans rapport avec la présentation (donc autre que de la génération de formatage ou de sortie HTML, de logique de test ou de boucle) dans cette Vue. Ce point est toutefois garantie par le mécanisme de validation du code. | |||