MVP contre MVC contre MVVM contre VIPER. Quoi de mieux pour le développement iOS ?

Idem que chaque maison a un sous-sol solide, chaque projet logiciel, a une architecture logicielle sur laquelle il est construit et chaque projet a sa propre structure d'application. Les types de modèles architecturaux peuvent varier, mais il y en a 4 les plus couramment utilisés - ceux que tout le monde informatique critique continuellement mais continue d'utiliser en même temps : MVC, MVP, MVVM et Viper (le dernier comme modèle d'architecture iOS principalement) . La comparaison de ces modèles et le choix d'un meilleur ajustement pour chaque cas de projet écrit par Swift seront découverts plus loin dans cet article.

Suivant l'ordre chronologique des choses, une fois que les premiers modèles de conception logicielle sont apparus, les problèmes communs de ces modèles d'architecture de développement ios n'ont pas tardé à arriver.

Par exemple, le problème de la communication serveur-client - comment interagissent les uns avec les autres ? Ou un autre problème - le problème de séparer la logique métier de l'application de la logique de l'application ; comment celui-ci devrait-il fonctionner en termes d'architecture d'application ? Grâce à eux, divers modèles de conception pour différentes couches d'architecture ont vu le monde; les plus connus d'entre eux sont :

- Modèle de conception Singleton.

Ce modèle permet à une classe d'être appliquée à un seul objet, et cette option est utile lorsqu'un nombre limité d'instances (ou une seule instance) est approuvé par le système.

- Modèle de conception de décorateur.

Contrairement au singleton, ce modèle (appelé aussi Wrapper avec le modèle Adapter), permet d'ajouter un comportement spécifique à un seul objet (statiquement ou dynamiquement), et tout cela sans affecter le comportement d'autres objets ce on partage une classe avec.

- Modèle de conception de pont.

Introduit pour la première fois par le célèbre Gang of Four - auteurs du livre "Design Patterns", ce modèle architectural "utilise l'encapsulation, l'agrégation et peut utiliser l'héritage pour séparer les responsabilités en différentes classes. la programmation devient très utile car les modifications du code d'un programme peuvent être effectuées facilement avec une connaissance préalable minimale du programme. [Source : Wiki]

Bien que ces modèles soient assez différents, les problèmes communs des auteurs de code se sont produits avec chacun d'eux ; par exemple, avec la « massivité » de Singleton. Singleton est trop global, car les dépendances de votre code sont cachées profondément dans votre application, au lieu d'être exposées dans les interfaces. C'est pourquoi, au cours du processus de développement du logiciel, de nouveaux modèles apparaissent constamment.

Les 4 modèles les plus couramment utilisés sont MVC, MVP, MVVM et VIPER (pour iOS principalement).

Développés dans le même ordre que ceux répertoriés, tous ont leurs propres avantages et défauts, provoquant de nombreux différends sur l'endroit où appliquer chacun. Accorder un peu plus d'attention aux meilleures pratiques qu'ils mettent en œuvre pourrait éclaircir un peu les choses.

modèle MVC

Le grand-père de tous les modèles logiciels, introduit pour la première fois au début des années 1970 par un informaticien norvégien Trygve Reenskaug, Module - View - Controller, largement connu sous le nom de MVC, est l'une des premières approches de modèle de la programmation orientée objet.

La partie View est chargée de tout afficher pour l'utilisateur du système (interfaces d'application mobile ou web, etc.). Model est généralement responsable des bases de données, des entités commerciales et du reste des données. À son tour, le contrôleur régule le travail du modèle, les données fournies à la base de données, l'affichage de la base de données mentionnée à la partie Vue et vice versa.

Aussi universel que puisse être le modèle MVC, les deux plus grands concurrents - Apple et Google ont leurs propres modèles représentant le système Modèle - Vue - Contrôleur. Le problème du système d'Apple réside dans la connexion étroite entre les parties View et Controller, presque au point d'avoir uni View & Controller, et laissant la partie Model séparée.

Par conséquent, il en résulte un processus de test médiocre - seul le modèle a pu être examiné, V&C (en raison de la connexion étroite qu'ils ont) ne peut pas du tout être testé.

La connexion robuste entre les segments Controller et View s'est avérée vraiment « malsaine » en ce qui concerne les logiciels, de sorte qu'un nouveau modèle a rapidement fait son apparition.

Modèle MVP.

Beaucoup d'entre nous ont entendu ce raccourci dans le contexte de Minimum Viable Product, mais en termes d'ingénierie logicielle, cela signifie quelque chose de différent. Le modèle Model View Presenter a quelques points clés, formant un vaste fossé entre celui-ci et MVC :

Modèle MVP

• La vue est plus faiblement couplée au modèle. Le Présentateur est responsable de lier le Modèle à la Vue.

• Test unitaire plus facile car l'interaction avec la vue se fait via une interface.

• Habituellement Afficher au présentateur = mapper un à un. Les vues complexes peuvent avoir plusieurs présentateurs.

Modèle MVC

• Les contrôleurs sont basés sur des comportements et peuvent être partagés entre les vues

• Peut être responsable de déterminer quelle vue afficher
  [Source : Infragistique]

Dans cet arrangement, les fonctions du modèle restent les mêmes ; Le présentateur est respectivement responsable de la logique métier. La partie V est celle qui présente un intérêt particulier - car elle est divisée en deux parties View et View Controller, qui sont responsables de l'interaction. Lorsqu'il y a une question MVVM vs MVC, le système de ce type résout le problème d'une « forte dépendance » des modes View et Controller utilisés dans le modèle MVC.

L'obstacle du test est également résolu dans ce cas, en tant que modèle, vue avec interaction utilisateur et présentateur - tous ces éléments peuvent être testés.
L'inconvénient encore existant est de la part de Presenter - mais beaucoup trop massif, mais prend en compte toutes les logiques commerciales existantes. C'est pourquoi l'acte suivant est entré en jeu, nommé…

Modèle MVVM

Un modèle architectural logiciel Model-View-ViewModel a été créé en 2005 par John Gossman, l'un des architectes de Microsoft. Les trois composants principaux du modèle MVVM sont respectivement :
Le modèle est « une implémentation du modèle de domaine de l'application qui comprend un modèle de données ainsi qu'une logique métier et de validation. Les exemples d'objets de modèle incluent les référentiels, les objets métier, les objets de transfert de données (DTO), les objets Plain Old CLR (POCO) et les objets d'entité et proxy générés. [Source : Microsoft]

La vue est à nouveau tout ce que l'utilisateur est capable de voir - la mise en page, la structure et l'apparence de tout sur l'écran. Fondamentalement, dans l'application, ce serait la page de l'application. View obtient et envoie des mises à jour à ViewModel uniquement, à l'exclusion de toutes les communications entre cette pièce et le modèle lui-même.

ViewModel est censé être une "chaîne d'interconnexion" entre les composants du système View et Model, et sa fonction principale est de gérer la logique de la vue. En règle générale, le modèle de vue interagit avec le modèle en appelant des méthodes dans les classes de modèle. Le modèle de vue fournit ensuite les données du modèle sous une forme que la vue peut facilement utiliser, comme l'indique Microsoft.

La principale différence entre MVC et iOS MVVM est que le modèle de distribution de MVVM est meilleur que dans le MVC précédemment répertorié, mais par rapport à MVP, il est également massivement surchargé. Les tests revêtent une importance particulière ici, car tout en écrivant clairement le code, vous ne pouvez pas garantir que l'ensemble du projet fonctionnera correctement - les tests, sur une note positive, aident à s'assurer qu'il fonctionnera.

La prochaine évolution des modèles architecturaux a été récemment publiée et est maintenant l'approche architecturale logicielle la plus récente.

Architecture VIPER iOS

À la recherche de la meilleure solution architecturale à offrir, les développeurs iOS du monde entier se sont heurtés à une approche dite d'« architecture propre », introduite par l'oncle Bob sur les Clean Coders - une plate-forme bien connue proposant des sessions de formation aux professionnels du logiciel du monde entier.

Clean Architecture divise la structure logique de l'application en plusieurs niveaux de responsabilité. À son tour, cette « séparation » résout les problèmes de dépendance étroite et augmente la disponibilité des tests à tous les niveaux.

VIPER pour le développement ios

VIPER est une réalisation de Clean Architecture pour les applications iOS. En règle générale pour tous les noms de modèles, il s'agit également d'un backronym, pour View, Interactor, Presenter, Entity et Routing. Chacune des parties du VIPER est responsable d'un certain élément, notamment :

1. View est responsable de la mise en miroir des actions que l'utilisateur effectue avec une interface

2. Les responsabilités du présentateur au sein du modèle VIPER sont assez limitées : il reçoit les mises à jour de l'entité, mais ne lui envoie aucune donnée ;

3. L'interacteur est la partie du système qui correspond réellement aux entités. Ce schéma fonctionne dans le sens suivant : Presenter informe Interactor des modifications apportées au modèle View, puis Interactor contacte la partie Entity et, avec les données reçues de l'Entity, Interactor revient à Presenter, qui commande à View de les refléter pour un utilisateur. Tous les modèles de données, toutes les entités et tous les sites web sont connectés à la partie Interactor.

4. L'entité est constituée d'objets contrôlés par Interactor (titres, contenu, etc.). Elle n'interagit jamais directement avec Presenter, uniquement via I-part.

5. Le routage (ou Wireframe comme on l'appelle parfois) est responsable de la navigation entre tous les écrans et, essentiellement, du routage. Wireframe contrôle les objets de UIWindow, UINavigationController et ainsi de suite.

En particulier dans le système architectural iOS, tout est construit sur un cadre appelé UIkit, qui comprend tous les composants d'Apple MVC, mais sans une connexion étroite qui rendait les codeurs fous auparavant.

Le module VIPER est aussi bénéfique pour les tests unitaires, car la distribution du grand patron permet de tester toutes les fonctionnalités disponibles. À bien des égards, c'était la principale difficulté rencontrée par les développeurs avec les précédents modèles de logiciels MVC, MVP et MVVM.

Pour couronner le tout.

Tous ces 4 modèles de conception de logiciels sont souvent appelés l'un des meilleurs modèles d'architecture pour le développement iOS, même s'ils sont tous loin d'être idéaux et certainement pas universellement utilisés pour chaque projet que vous développez. Du côté sombre, voici une courte liste des problèmes que chaque modèle a :

• MVC, MVP, MVVM - tous ont ce problème de "connexion étroite", ce qui rend l'introduction de mises à jour de développement et leur test par la suite une tâche assez difficile à accomplir.

• VIPER vs MVVM, MVC ou MVP , est considéré comme un cas gagnant ; bien que malgré sa grande flexibilité et sa grande testabilité, il présente également de nombreuses nuances difficiles à générer.

Existe-t-il une solution 100% solide ? Pas vraiment, mais pour chacun de vos projets, l'un de ces 4 modèles d'applications iOS pourrait être exactement ce dont vous avez besoin. Et si ce n'est pas le cas, alors un mélange de deux le serait. Ou peut-être même trois. On dit que la fortune favorise les audacieux, alors pourquoi ne jouez-vous pas avec audace avec les modèles de conception de logiciels ?

Écrit par Max Mashkov et Elina Bessarabova.