31,029
edits
Langages et normes: Difference between revisions
Jump to navigation
Jump to search
m
→Design Pattern d'Interface Graphique (MVC)
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 518: | Line 518: | ||
==Design Pattern d'Interface Graphique (MVC)== | ==Design Pattern d'Interface Graphique (MVC)== | ||
Il existe plusieurs design pattern pour les interfaces utilisateurs (MVC, MVP, MVVM). | 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 | Beaucoup confonde ce design pattern avec celui consistant à utiliser un framework de templates. C'est sans rapport. Un framework de templates (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. | -> Dolibarr utilise le Design Pattern '''MVC''' (Model - Vue - Contrôleur). 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 ( | Beaucoup de frameworks ont fait le choix de mettre la partie de code C (Contrôleur) 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 jongler 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 (Contrôleur) est donc le code qui se trouve sont la balise | ||
<pre> | <pre> | ||
/* | /* | ||