Modèle–vue–adaptateur

Modèle–vue–adaptateur ( MVA ) ou contrôleur médiateur MVC est un modèle d'architecture logicielle et une architecture à plusieurs niveaux . Dans les applications informatiques complexes qui présentent de grandes quantités de données aux utilisateurs, les développeurs souhaitent souvent séparer les problèmes de données (modèle) et d'interface utilisateur (vue) afin que les modifications apportées à l'interface utilisateur n'affectent pas la gestion des données et que les données puissent être réorganisées sans modifier l'interface utilisateur. MVA et MVC traditionnel tentent tous deux de résoudre ce même problème, mais avec deux styles de solution différents. Le MVC traditionnel organise le modèle (par exemple, les structures de données et le stockage), la vue (par exemple, l'interface utilisateur) et le contrôleur (par exemple, la logique métier) dans un triangle, avec le modèle, la vue et le contrôleur comme sommets, de sorte que certaines informations circulent entre le modèle et les vues en dehors du contrôle direct du contrôleur. L'adaptateur modèle–vue–contrôleur résout ce problème de manière assez différente du modèle–vue–contrôleur en organisant le modèle, l'adaptateur ou le contrôleur médiateur et la vue de manière linéaire sans aucune connexion directe entre le modèle et la vue.

La vue est complètement découplée du modèle de telle sorte que la vue et le modèle ne peuvent interagir que via le contrôleur médiateur ou l'adaptateur entre la vue et le modèle. Grâce à cette disposition, seul l'adaptateur ou le contrôleur médiateur a connaissance du modèle et de la vue, car il est de la seule responsabilité de l'adaptateur ou du contrôleur médiateur de s'adapter ou de servir de médiateur entre le modèle et la vue, d'où les noms d'adaptateur et de médiateur. Le modèle et la vue sont intentionnellement maintenus inconscients l'un de l'autre. Dans le MVC traditionnel, le modèle et la vue sont conscients l'un de l'autre, ce qui peut permettre un couplage désavantageux des préoccupations de vue (par exemple, l'interface utilisateur) dans le modèle (par exemple, la base de données) et vice versa, alors que l'architecture aurait pu être mieux servie par le schéma de la base de données et la présentation des informations dans l'interface utilisateur étant entièrement séparés l'un de l'autre et autorisés à diverger l'un de l'autre radicalement. Par exemple, dans un éditeur de texte , le modèle pourrait être mieux une table de pièces (au lieu, par exemple, d'un tampon d'espacement ou d'une liste chaînée de lignes ). Mais l'interface utilisateur doit présenter l'état de repos final des modifications apportées au fichier, et non une présentation directe de surcharge d'informations sur les deltas bruts méticuleux d'annulation/rétablissement de la table des pièces et les opérations incrémentielles sur ce fichier depuis le début de la session d'édition en cours.

Cette séparation des préoccupations permet à une grande variété de vues différentes d'accéder indirectement au même modèle, soit via exactement le même adaptateur, soit via la même classe d'adaptateurs. Par exemple, un modèle et un schéma de stockage de données sous-jacents et une technologie peuvent être accessibles via différentes vues (par exemple, l'interface utilisateur graphique Qt , l'interface utilisateur graphique Microsoft MFC , l'interface utilisateur graphique GTK+ , l'interface utilisateur graphique Microsoft .NET , l'interface utilisateur graphique Java Swing , le site Web Silverlight et le site Web AJAX ) où (contrairement au MVC traditionnel) le modèle est complètement inconscient des informations qui circulent vers ces interfaces utilisateur . L'adaptateur ou la classe d'adaptateurs permet au modèle de ne pas se rendre compte qu'il prend en charge plusieurs interfaces utilisateur et peut-être même qu'il prend en charge cette variété simultanément. Pour le modèle, ces multiples types d'interface utilisateur ressembleraient à plusieurs instances d'un utilisateur générique inconscient du type de technologie.

De même, une interface utilisateur peut être intentionnellement ignorée d'une grande variété de modèles différents qui peuvent sous-tendre le contrôleur ou l'adaptateur médiateur. Par exemple, le même site Web peut être ignoré du fait qu'il peut être servi (A) par un serveur de base de données SQL tel que PostgreSQL , Sybase SQL Server ou Microsoft SQL Server qui a une logique métier intégrée au serveur de base de données via des procédures stockées et qui contient des transactions que le serveur peut annuler ou (B) par un serveur de base de données SQL tel que MySQL qui ne dispose pas d'une ou plusieurs de ces fonctionnalités, ou (C) par une base de données RDF non SQL , car le site Web interagit uniquement avec le contrôleur ou l'adaptateur médiateur et jamais directement avec le modèle.

De plus, plusieurs adaptateurs peuvent être créés pour modifier la façon dont une vue présente les données pour un modèle donné. Par exemple, différents adaptateurs peuvent imposer différents ensembles de données primitives, qui à leur tour imposent une logique métier différente pour la même base de données sous-jacente et pour le même site Web présenté de manière externe. Dans ce scénario, une classe de différents adaptateurs ou contrôleurs intermédiaires peut représenter les variations de logique métier entre le même modèle de base de données et la même vue de site Web.