Différence entre MVVM et MVP Différence Entre

Le but du développement de logiciels est de créer des solutions qui répondent aux besoins et aux problèmes des utilisateurs et des entreprises. Pour ce faire, différentes technologies et modèles d'architecture tels que Model-View-ViewModel (MVVM) et Model-View-Presenter (MVP) sont utilisés.

Comme pour tout ce qui est fabriqué, la première étape est la phase de planification et de conception. Le processus de conception de logiciel peut être une spécification basée sur l'ensemble d'outils technologiques préféré, et il peut englober toutes les activités, de la conception à la planification, en passant par la mise en œuvre, jusqu'aux mises à jour et aux modifications.

Il couvre la conception architecturale de bas niveau et de haut niveau, basée sur des modèles d'architecture sélectionnés, et cartographie des solutions réutilisables en utilisant des modèles de conception.

Structure d'application logicielle

L'architecture logicielle définit la structure d'une application qui répond aux exigences techniques, opérationnelles et de l'utilisateur et fait référence à la manière dont le code est organisé et géré.

Décider de l'architecture d'une application logicielle est essentiel car ce n'est pas une partie facile et modifiable d'une application déjà développée; par conséquent, le modèle architectural doit être choisi avant toute programmation.

Les modèles architecturaux sont quelque peu différents des modèles de conception car leur portée est beaucoup plus large en traitant des problèmes plus techniques tels que les performances et les limitations du matériel, et la haute disponibilité. Les exemples de différents modèles d'architecture sont MVC, MVVM et MVP.

D'autre part, les modèles de conception sont des bonnes pratiques formalisées qui facilitent le développement orienté objet réutilisable et sont plus faciles à maintenir et à modifier que l'architecture d'une application.

Patrons d'architecture

Model View Controller (MVC) a été l'un des premiers modèles architecturaux développés pour les applications web, gagnant en popularité du milieu à la fin des années 90, notamment avec la communauté Java.

Les frameworks les plus récents, tels que Django pour Python et Rails (Ruby on Rails), se concentrent sur le déploiement rapide, c'est pourquoi MVC occupe la part de marché en tant que grande attraction dans les modèles architecturaux.

Traditionnellement, le développement de l'interface utilisateur contenait beaucoup de code pour gérer une logique compliquée, de sorte que les modèles d'architecture étaient conçus pour réduire le code au niveau de l'interface utilisateur, le rendant plus «propre» et gérable.

Ainsi, avec le pattern MVC, une application web est composée de

• Model (data)
• View (interface pour visualiser et manipuler les données)
• Controller (opérations et les actions effectuées sur les données)

Le modèle gère les données et la logique métier et il y a non dépendances entre le modèle et le contrôleur < ou Voir . La

Vue présente les données à l'utilisateur dans le format supporté et la disposition requise, et lorsque le Contrôleur reçoit les demandes des utilisateurs (pour récupérer les données), il appelle les ressources nécessaires pour compléter la demande. Appliquons ce modèle à la construction d'une librairie en ligne.

Les utilisateurs peuvent rechercher, consulter, enregistrer et acheter des livres, ainsi que gérer leurs profils et leurs listes de livres. Lorsqu'un utilisateur clique sur la catégorie SCI-FI, tous les livres associés doivent s'afficher comme disponibles.

Les

Contrôleurs gèrent les actions qui gèrent les livres (liste, ajouter, voir, etc.). Il peut y avoir plusieurs Contrôleurs avec un Contrôleur principal «dirigeant le trafic». Pour cet exemple, le contrôleur

s'appelle controller_books. php et le Modèle (par exemple model_books.php) gère les données et la logique liées aux livres. Enfin, des

vues différentes seront requises, comme lors de l'ajout de livres au panier en ligne ou lors de la visualisation des détails du livre avec des images et des critiques. Les contrôleurs

. php reçoit l'action (requête utilisateur) du contrôleur principal (par exemple index.php ). Les controller_books. php analyse la requête et appelle les model_books. php (les données) pour retourner la liste des livres SCI-FI. La responsabilité du

modèle consiste à fournir cette information, en utilisant toute logique appliquée (en utilisant des filtres de recherche). Le Contrôleur prend alors l'information et la passe à la Voir (vue de recherche, vue d'impression, vue de détail, etc.) et l'information est présentée (via Voir >) à l'utilisateur qui a initié la requête. Voici les principes de base du modèle MVC, qui a évolué des variations de génération de modèles d'architecture, tels que MVP (Model-View-Presenter), MVVM (Model-View-ViewModel), Hierarchical-Model-View-Controller (HMVC), et Model-View-Adapter (MVA), etc.

Modèle MVP

Présentateur modèle (MVP)

Le modèle

MVP existe depuis un moment et est une variante de MVC. Il a été conçu spécifiquement pour l'automatisation des tests où l'objectif était d'augmenter la quantité de code pouvant être testé via l'automatisation, et le modèle résout certains problèmes avec la couche de présentation, en isolant la logique métier de l'interface utilisateur. L'écran est la vue, les données affichées sont le modèle et le présentateur relie les deux.

MVP

comprend les composants suivants avec des responsabilités distinctes: Modèle

• (définit les données à afficher) Afficher
• (affiche les données du modèle et achemine les demandes d'utilisateur au Présentateur). Presenter
• (interagit entre la vue et le modèle et les relie ensemble) La

vue (une page Web) affiche et gère les contrôles de page en transférant les événements (requêtes utilisateur) vers Presenter qui ont été lancés dans View . Le

Presenter répond à ces événements en lisant et en mettant à jour le Modèle pour changer le View et par conséquent, la responsabilité du Presenter est pour lier les modèles et Voir . Après avoir regardé les modèles

MVC et MVP , la communauté a des responsabilités distinctes pour chaque composant et favorise la séparation entre la Vue (UI) et Modèle (données). Les différences significatives entre ces modèles sont plus évidentes dans la façon dont les modèles sont mis en œuvre. MVP

peut être un modèle complexe à implémenter pour des solutions avancées, mais il présente certainement de grands avantages s'il est implémenté comme une solution bien conçue, bien que ce ne soit pas forcément le bon choix pour des solutions simples. Modèle MVVM

Modèle-View-ViewModel (MVVM)

Le modèle

MVVM a été spécialement conçu pour les plates-formes Windows Presentation Foundation (WPF) et Microsoft Silverlight. utilisé sur toutes les plates-formes XAML [i] . WPF est un système Microsoft qui affiche les interfaces utilisateur dans les programmes basés sur Windows et a été publié pour la première fois dans.NET Framework 3. 0.

MVVM

a été affiné à partir de MVC ., View est actif avec les comportements, les événements et la liaison de données, et View se synchronise avec le ViewModel (qui permet la séparation de la présentation et expose les méthodes et les commandes pour gérer et manipuler le Modèle . MVVM

comprend trois composants de base: Modèle

• (représente les données avec validation et logique métier) Voir > (La vue est responsable de la définition de la structure, de la disposition et de l'apparence de ce que l'utilisateur voit sur l'écran.) Idéalement, la vue est définie uniquement avec XAML, avec un code-behind limité qui ne contient pas de logique métier. liaison entre les
• View et ViewModel pour afficher les synchronisations du modèle et du ViewModel avec la vue) ViewModel (sépare la vue du e Model, et expose des méthodes et des commandes pour manipuler les données (Modèle).
• La Vue

reçoit les données du ViewModel (via la liaison de données et les méthodes), et lors de l'exécution, la Vue change en réponse aux événements le ViewModel . Le ViewModel

sert de médiateur entre les View et Model et gère la logique View . Il interagit avec le modèle - en prenant les données du modèle et en les présentant à la vue à afficher. Ces composants sont tous découplés les uns des autres, ce qui permet une plus grande flexibilité pour travailler de manière indépendante, isoler les tests unitaires et les échanger, sans affecter aucun autre composant. Cette structure permet aux

modèles

et aux autres composants d'évoluer indépendamment, permettant aux développeurs de travailler simultanément sur différents aspects de la solution. Par exemple, lorsque les concepteurs travaillent sur la Vue , ils génèrent simplement des échantillons de données sans avoir besoin d'accéder aux autres composants. Cela facilite la nouvelle conception de l'interface utilisateur lorsque la Vue est implémentée dans XAML. Comme mentionné précédemment avec MVP, les solutions simples n'auraient pas besoin de modèles d'architecture et de design, comme "Hello World!"Est trop basique pour suivre n'importe quel modèle; Cependant, à mesure que de nouvelles fonctionnalités, fonctions et composants sont introduits, la complexité de l'application augmente, tout comme la quantité de code à gérer. En résumé Depuis le début du développement de l'interface utilisateur, les modèles de conception deviennent de plus en plus populaires pour faciliter le processus de développement, rendre les applications plus évolutives et faciliter les tests.

Différence illustrée entre MVP et MVVM Patterns:

Dans

MVP

• et MVVM , la View est le point d'entrée de l'application > Dans MVP , il existe un mappage un-à-un entre les
• View et Presenter , où dans MVVM , la relation est une -to-many entre View et ViewModel . MVP est principalement utilisé pour les applications Windows Forms et Windows Phone et MVVM
• est conçu pour Silverlight, WPF, Knockout / AngularJS, etc.