Définition
Model View Controller est une architecture logicielle principalement utilisée dans les applications GUI pour séparer une application en trois composants principaux: la vue pour afficher et représenter les données sous différentes formes, le contrôleur pour gérer les actions et les entrées utilisateur et le modèle où nous mettons notre business model .
C'est la définition la plus répandue sur Internet. Le problème, en passant par plusieurs références, est que je trouve de légères différences dans la manière dont ces niveaux communiquent entre eux. En outre, j'ai remarqué qu'il y a un manque de ressources sur la façon de mettre en œuvre correctement ce modèle. En effet, lorsque nous codons une application par rapport à cette architecture, nous rencontrons de nombreux défis et nous serons dans l'obligation de prendre des décisions qui peuvent ou non convenir.
Histoire
MVC a d'abord été présenté par Trygve Reenskaug dans l'un de ses livres blancs, qui peut être trouvé ici. Le Smalltalk-80 a été l'une des premières implémentations utilisant cette architecture, bien qu'il ait fait quelques changements par rapport à ce qui a été décrit par Trygve Reenskaug, car leur produit est devenu plus grand et plus mature.
Depuis lors, MVC a eu de nombreuses variantes, comme MVP (Model View Presenter), HMVC (hiérarchique modèle-vue-contrôleur), et d'autres.
Implémentations MVC
Dans cette section, j'ai décidé de comparer quatre architectures à partir de quatre ressources différentes: l'article de Trygve Reenskaug, «Patterns of enterprise application architecture» de Martin Fowler, Patterns: éléments de logiciels orientés objet réutilisables - Gang Of Four et le framework PureMVC.
Trygve Reenskaug
Comme décrit dans sondocument, le modèle est un composant indépendant contenant notre logique métier (comme c'est le cas pour les autres références). La vue construit l'interface et gère ses composants. Il reçoit également les commandes du contrôleur, met à jour le modèle et interroge sur le nouvel état du modèle. Enfin, le contrôleur gère les actions et les entrées de l'utilisateur.
Comme vous pouvez le constater, la vue a de nombreuses responsabilités. De plus, si nous avions beaucoup de vues et de contrôleurs, nous trouverions un problème à faire interagir ces objets les uns avec les autres, car chaque objet devra connaître les autres.
Modèles d'architecture d'application d'entreprise
Le modèle contient à nouveau notre logique métier et la vue fait tout le reste, bien que nous puissions utiliser le contrôleur si nécessaire pour gérer les actions de l'utilisateur. Cette conception est naturelle à suivre, mais la vue, encore une fois, a de nombreuses responsabilités.
Design Patterns: éléments de logiciels orientés objet réutilisables
Le modèle contient notre logique métier et peut notifier les vues en utilisant le modèle d'observateur.
La vue utilise le modèle composite déjà construit, donc il n'y a pas d'implémentation du modèle dans le projet. La vue demande également des mises à jour lors de la réception de notifications du modèle.
Note: Ici c'est un peu compliqué car vous devrez gérer la façon dont le modèle notifie les vues. Vous ne voulez probablement pas que toutes les vues appelant le modèle à changer ne les concernent pas.
Le contrôleur peut être utilisé avec le modèle de stratégie, mais il existe tout de même un besoin de communication entre les contrôleurs. Par conséquent, il se retrouve avec un contrôleur connaissant tous les autres contrôleurs.
Remarque: L'utilisation de la Factory est importante pour créer et relier des objets et retourner un contrôleur par défaut.
PureMVC
PureMVC est un framework utilisé pour développer des applications basées sur l'architecture MVC. Il existe dans de nombreux langages tels que Java, ActionScript, PHP et autres. Le référentiel officiel peut être trouvé ici.
Dans cette implémentation, il existe d'autres composants, à l'exception du modèle, de la vue et du contrôleur, qui permettent d'atteindre la conception souhaitée. Le framework utilise des proxies qui exposent l'API du modèle, des médiateurs pour manipuler et réutiliser des vues, des commandes qui sont fondamentalement logiques à appeler chaque fois que nécessaire, et une façade pour fournir un point unique pour manipuler l'application. Vous pouvez trouver plus de détails ici.
Les médiateurs et les commandes peuvent facilement communiquer les uns avec les autres d'une manière faiblement couplée à travers le mécanisme d'écoute de notification (une implémentation légèrement différente du modèle d'observateur). En outre, l'utilisation du proxy est très efficace pour la mise en cache et l'ajout de nouvelles responsabilités non concernées par le modèle.
Mais, comme vous pouvez le constater dans le projet, le médiateur a encore de nombreuses responsabilités contrairement aux commandes qui semblent n'avoir qu'un rôle dans le démarrage de l'application. En outre, le système de notification est centralisé dans la vue, ce qui peut avoir des inconvénients car nous pouvons perdre le contrôle de notre système avec des notifications lancées partout dans l'application. De plus, la notification contient en soi l'objet envoyé ou reçu. Cette technique a certaines limitations comme la gestion du type d'objet (test et casting) et le fait que nous ne sommes limités qu'à un seul objet (nous ne pouvons pas envoyer plus d'un objet dans la notification).
Conclusion
Comme vous pouvez le voir, l'écriture d'une application avec un bon design basé sur le MVC est une architecture très difficile qui peut causer des problèmes si de mauvaises décisions sont prises. Je pense que les principaux problèmes viennent de la nécessité de définir strictement les rôles de la vue et du contrôleur même dans les moindres détails et d'assurer un bon mécanisme de communication entre ces composants. Les exemples présentés ici ne sont pas exhaustifs, vous pouvez trouver d'autres implémentations et modèles utilisés avec l'architecture MVC.
Aucun commentaire