Wiki - 1 output

Redirected from HMVCP

Si vous n’êtes pas familier avec les concepts de MVC et HMVC, je vous invite à lire l’article très précis sur Wikipedia puis réviser le concept de HMVC chez Max-Koder.

Le modèle MVC apporte des solutions pour la couche présentation de l’application, mais n’assure pas la séparation des processus de calculs : si on s’appuie uniquement sur ce modèle MVC pour écrire une application, on aura tendance à écrire les calculs dans le contrôleur, dont la tâche ne doit être dédiée qu’à la synchronisation entre vue, modèle et processus.

La bonne pratique promue dans ce framework consiste donc entre autres à fusionner les patrons de conception Modèle-vue-contrôleur et Présentation-abstration-contrôle en séparant les différents éléments constitutifs de votre applcation :

Le paradigme HMVCP selon it.rocks

• Le Modèle : il décrit vos données, et les règles de gestion fondamentales qui les relient pour assurer leur intégrité.
  Contrairement à ce qui est décrit en général en MVC, dans it.rocks le Modèle ne comporte pas de fonction d’interactions avec la base de données ou le stockage des données : la description “métier” de vos données se veut le plus possible indépendante de son mode de stockage.

• Le Dao : “Data access object” : il donne les outils pour relier les données du modèle avec les données stockées en bases de données, fichiers, etc.

• La Vue : elle affiche les données et résultats de calculs à l’utilisateur, et reçoit les interactions de l’utilisateur pour les traduire en appel de contrôleurs.

• Le Processus : les tâches de traitements et calculs complexes sont dissociées du modèle et du contrôleur pour être réalisées dans des parties dédies de votre application.

• Le Contrôleur : chef d’orchestre de votre application, il fait le lien entre le modèle – en utilisant le Dao, le processus et la vue.

Enfin, les contrôleurs sont hiérarchisés pour spécialiser et garder indépendante chaque partie de l’application, répondant ainsi aux principes du HMVC, en appliquant ces principes, issus ou complétant le pattern :

• Le Framework est livré avec des modules d’accès aux données implicites, vues et contrôleurs par défaut, dont le but affiché est de répondre de manière la plus poussée possible aux problématiques de gestion les plus courantes. Ainsi sauf besoin spécifiques vous pouvez développer la base de votre application en ne programmant que ses modèles.

• La personnalisation de l’interface utilisateur peut être réalisée sans nécessité de programmer de contrôleur, en modélisant tout ou partie de templates HTML nécessaire.

• La hiérarchie des vues et contrôleurs est possible par appels directs de contrôleurs ou de templates depuis des templates HTML de vues ou d’autres contrôleurs.

• Les différentes composantes de l’application respectant les principes de programmation objets, il est toujours possible de construire ces élements en héritant des propriétés des éléments déjà présents dans le Framework ou développés par des tiers.

• Enfin les comportements standards ou développés dans des modules logiciels existants qu’on ne souhaite pas modifier peuvent être personnalisés en utilisant la composition de classes ou des plugins faisant appel à des branchements AOP.