Utilisateur:Lgeneau/Brouillon
Le patron d'architecture est une notion fondamentale dans la réalisation d'un logiciel. Cette notion s’adaptant aux systèmes sur lesquels l'application est déployée, la mise en place d'un patron varie. Ainsi, un même patron pensé pour les applications mobiles ne sera pas nécessairement valable et pour les systèmes Android et pour les systèmes iOS pour ne citer qu'eux.
Définitions et histoire[modifier | modifier le code]
Patron d'architecture[modifier | modifier le code]
En ingénierie logicielle un patron d'architecture correspond à une solution réutilisable et admise comme bonne pratique à un problème récurrent d'architecture dans la conception d'un système ou logiciel informatique.
Les patrons de conception[modifier | modifier le code]
Les patrons d'architecture sont à distinguer des patrons de conception même si par abus de langage l'expression "design pattern" tend à désigner aussi bien l'un que l'autre.
S'ils leurs sont similaires, les patrons d'architecture ont une portée plus large. Là où les patrons de conception fournissent une solution à un problème de conception de logiciel, les patrons d'architecture fournissent une solution générale servant de modèle dans la division en modules du logiciel à réaliser.
Histoire[modifier | modifier le code]
Si le terme d'architecture logicielle a fait son apparition à la fin des années 60[1], c'est dans les années 90 que l'on voit apparaître la définition et codification des aspects de ce domaine.[2]
C'est à cette même époque que le livre du « Gang of Four » (GoF, Erich Gamma, Richard Helm, Ralph Johnson (en) et John Vlissides (en)) intitulé Design Patterns – Elements of Reusable Object-Oriented Software[3] formalise la notion de patron de conception. On peut donc supposer la formalisation du concept d'architecture logicielle durant ces mêmes années même si certains patrons furent inventés et utilisés bien auparavant (comme MVC qui fut introduit dans Smalltalk-79 par Trygve Reenskaug dans les années 70[4]).
Liste des patrons[modifier | modifier le code]
Avant de lister les différents patrons, il est important de souligner que Microsoft déclarait en 2008[5], et non sans raison, que les applications mobiles reposent sur une architecture trois tiers, à savoir:
- la présentation des données, c'est-à-dire ce que l'utilisateur voit
- le traitement métier des données, correspondant à la mise en place de la logique applicative
- l'accès aux données persistantes, correspondant aux données conservées même lorsque l'utilisateur a quitté l'application
Model-View-Whatever[modifier | modifier le code]
Le but des patrons de type MV(X) est de séparer la présentation des données de leur traitement afin d'augmenter la cohésion et diminuer le couplage au sein de l'application[6]. Trois principaux patrons les composent: MVC, MVVM et MVP.
Modèle-Vue-Contrôleur[modifier | modifier le code]
Premier défini parmi les patrons Modèle-Vue-X, le patron MVC a été inventé par Trygve Reenskaug pour les applications SmallTalk en 1979.
MVC classique[modifier | modifier le code]
Lors d'une interaction de l'utilisateur sur la Vue, cette dernière est transmise au Contrôleur qui met alors à jour le modèle en conséquence.
Le Contrôleur notifie ensuite la Vue du changement afin que celle-ci aille cherche la donnée dans le Modèle et se mette à jour[7].
Le grand désavantage du patron MVC classique réside dans la forte interdépendance des composants rendant les test unitaires très compliqués à implémenter[8].
MVC Apple[modifier | modifier le code]
L'API Cocoa Touch[9] (anciennement Cocoa) fonctionne de façon à placer le Contrôleur comme intermédiaire entre la Vue et le Modèle offrant ainsi une solution face à l'interdépendance des composants précédemment mentionnée dans le cadre du patron MVC classique[10].
Ce comportement est cependant décrié, les classes UIView et UIViewController de l'API Cocoa étant bien plus liées qu'elles ne devraient l'être dans une architecture MVC[7].
La lourdeur des Contrôleurs dans ces conditions peut poser problème, notamment dans le cadre d'applications complexes. De plus cette liaison de la Vue et du Contrôleur maintient la difficultés d'implémenter des tests unitaires.
Le répertoire GitHub de Wasin Thonkaew fournit une implémentation en Swift du patron MVC.
Modèle-Vue-Présenteur[modifier | modifier le code]
La patron MVP est un dérivé de MVC. La liaison entre la Vue et le Modèle est supprimée, on retombe donc sur l'architecture promise par le MVC d'Apple. Cependant, pour parvenir à l'implémentation de cette architecture, il faut ranger les classes UIView et UIViewController dans les Vues et définir comme Présentation un intermédiaire indépendant. Voici l'implémentation de Wasin Thonkaew du patron MVP en Swift. Cette implémentation offre enfin une solution pour du code plus facilement testable.
Modèle-Vue-VueModèle[modifier | modifier le code]
C'est Microsoft qui est à l'origine de MVVM, un patron apparu en 2004. MVVM ajoute au patron MVP la liaison entre la Vue et le superviseur (nommé VueModèle) sur les données ainsi que les interactions de l'utilisateur.
L'implémentation par W
asin Thonkaew du patron MVVM est réalisé sans Framework. L'usage de bibliothèques telles que RxSwift est cependant très courant pour permettre la liaison entre la Vue et le VueModèle.
Clean Architecture[modifier | modifier le code]
En 2012 Robert C. Martin a publié sur son blog[11] un article sur la notion "d'architecture épurée". Une telle architecture permet à l'application d'être:
- indépendante de tout Framework
- testable
- indépendante de l'interface utilisateur
- indépendante de la Base De Données
- indépendante des sources externes
Cette architecture se base sur la règle de la dépendance: tout dépendance du code source ne peut pointer que sur un composant du logiciel se trouvant dans un cercle plus au centre du schéma.
Ce patron est une synthèse des patrons:
- d'architecture hexagonale
- d'architecture en oignon[12]
- d'architecture Screaming
- DCI
- BCE
La notion d'architecture épurée aura inspiré deux patrons d'architecture sur iOS: VIPER et VIP.
VIPER[modifier | modifier le code]
VIPER est un patron décrit en juin 2014 par Jeff Gilbert et Conrad Stoll dans un article intitulé "Architecting iOS Apps with VIPER".[13] Contrairement aux précédents patrons, celui-ci est en 5 tiers, ajoutant un Routeur chargé de la gestion des écrans et un Interactor insérant une couche entre la Présentation et la persistance (Entité) des données.
VIPER propose un découplage nettement plus important que les autres patrons, s'octroyant ainsi une très grande testabilité. Son coût en revanche se trouve dans sa maintenabilité puisqu'il requiert l'implémentation de beaucoup d'interfaces pour fonctionner.
VIPER est un patron qui n'est approprié que pour des applications complexes, son coût en
maintenabilité n'étant pas raisonable dans le cadre d'une petite application.
VIP[modifier | modifier le code]
VIP est une variante de VIPER proposée par Raymond Law dans son article "Clean Swift iOS Architecture for Fixing Massive View Controller".[14]
Contrairement à VIPER, le VueContrôleur est séparé de la Vue, mis au centre du patron à la place de Présentation et l'interaction bidirectionnelle entre la Présentation et le VueContrôleur est devenu un triangle d'interaction entre le VUeContrôlleur, l'Interactor et la Présentation. Cette gestion circulaire de l'information peut-être vue comme une amélioration de VIPER.
Architecture avec SwiftUI[modifier | modifier le code]
Lors de la WWDC19, Apple a introduit SwiftUI qui n'utilise aucun Contrôleur.[15] C'est un remède au problème des VueContrôleurs massifs de Swift mais c'est aussi un changement de paradigme notable, le patron MVC ayant été depuis longtemps un standard sur les platformes Apple.
Références[modifier | modifier le code]
- P. Naur et B. Randell, « Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968 », Brussels, NATO, Scientific Affairs Division, (consulté le )
- Garlan & Shaw, « An Introduction to Software Architecture », (consulté le )
- Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (trad. Jean-Marie Lasvergères), Design Patterns - Catalogue de modèles de conceptions réutilisables, France, Vuibert, , 490 p. [détail des éditions] (ISBN 2-71178-644-7)
- Notes and Historical documents from Trygve Reenskaug, inventor of MVC.
- J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr et Akshay Bogawat, « Mobile Application Pocket Guide v1.1 », Redmond, Microsoft, (consulté le )
- ENSI CAEN, « Patrons d'architecture MVC, MVP et MVVM - gui-patterns.pdf », sur foad.ensicaen.fr, (consulté le )
- (en) Bohdan Orlov, « iOS Architecture Patterns », sur medium.com, (consulté le )
- (en) « iOS Architecture Patterns and Best Pratices for Advanced Programming - 2020 », sur thinkmobiles.com (consulté le )
- (en) « Cocoa (Touch) », sur developer.apple.com (consulté le )
- (en) « Model-View-Controller », sur developer.apple.com (consulté le )
- (en) Robert C. Martin, « Clean Code Blog », sur blog.cleancoder.com, (consulté le )
- (en) Jeffrey Palermo, « The Onion Architecture : part 1 | Programming with Palermo », sur jeffreypalermo.com, (consulté le )
- (en) Jeff Gilbert et Conrad Stoll, « Architecting iOS Apps with VIPER », sur objc.io, (consulté le )
- (en) Raymond Law, « Clean Swift iOS Architecture for Fixing Massive View Controller », sur clean-swift.com (consulté le )
- (en) Matěj Kašpar Jirásek, « MVC without the C: What will SwiftUI change in app architecture? », sur blog.thefuntasty.com, (consulté le )