Comprendre les Concepts Objets – Les Patrons d’Architecture

Sommaire

Programmation Orientée Objet, Design/Architectural Patterns, … Vous en avez déjà entendu parler. Mais savez vous précisément ce en quoi ça consiste ?

Ces 8 articles vous permettront de comprendre les grands principes qui se cachent derrière ces termes techniques, mais également d’apprendre comment et pourquoi les utiliser.

• La Programmation Orientée Objet
• Introduction à UML : Diagrammes de classe
• Concepts de base de POO
• Les Patrons de Conception (Design Patterns)
• Les Patrons d’Architecture (Architectural Patterns)
• Concepts avancés de POO
• Qualité de Code
• Web Services

Qu’est-ce qu’un Patron d’Architecture ?

Vous vous souvenez des Patrons de Conception ? Et bien un Patron d’Architecture est une forme de Patron de Conception, créé dans le but de définir une architecture pour votre application. 

Si vous souhaitez une belle définition : Un Patron d’Architecture constitue la meilleure solution connue à un problème d’architecture récurrent.

Si vous avez compris ce qu’est un Patron de Conception, vous comprendrez rapidement la différence avec un Patron d’Architecture. Sinon, je vous invite à relire le cours sur les Patrons de Conception.

On pourrait dire qu’un Patron d’Architecture est un Patron de Conception, conçu de manière à définir l’application dans son ensemble, ou du moins une grande partie de l’application. Un Patron de Conception permet de résoudre un problème en s’appuyant sur des classes essentiellement. Les Patrons d’Architecture, eux, vont s’appuyer fortement sur les “packages”, ou même sur des serveurs/modules/services. Chaque package pourrait accueillir un nombre théoriquement infini de classes. Le but est simplement d’organiser l’application, et de séparer aux maximums les rôles principaux qu’on trouve dans une application.

Les différents patrons d’architecture

Il en existe plein, néanmoins nous ne verront que 3 classiques dans ce cours :

• MVC
• MVVM
• N-Tiers

Comme pour les patrons de conception, nous nous appuierons sur l’UML et ses fameux diagrammes de classe pour expliquer le fonctionnement de chaque patron d’architecture. Il est donc essentiel de maîtriser ce langage.

Le MVC

Le MVC, ou Model View Controller (Modèle Vue Contrôleur en français) est probablement le patron d’architecture le plus employé aujourd’hui. Son principe est simple, séparer l’application en 3 parties distinctes. Cette séparation est très pratique dans le cadre d’un projet en équipe, puisqu’il correspond assez bien aux différents rôles qu’on trouve dans une équipe. En effet, les compétences requises pour mener à bien un projet sont souvent :

• Base de données
• Design (Front-End)
• Développement général (Back-End)

De cette manière, un spécialiste en base de données peut se charger des requêtes, afin de les optimiser au maximum. Le designer peut s’occuper de réaliser une charte graphique, de positionner les éléments, ou d’une manière générale, gérer toute la partie Front-End. Et enfin, un développeur plus général (ou Back-End) peut s’occuper de mettre tout cela en relation.

On trouve souvent ce diagramme avec une flèche allant de Model à Controller, et parfois même de Model à View. Tout est une question de ce que vous mettez dans le Model. En effet, le MVC est un concept très basique, qui est souvent utilisé pour architecturer des applications qui impliquent d’autres packages. De plus, pour une application Web par exemple, View peut retourner le code HTML qu’il a généré au Controller pour que ce dernier le retourne au client sous forme de réponse.

Vous vous êtes déjà retrouvé dans une situation où un de vos collègue s’est vu modifier les mêmes fichiers que vous, au même moment. Et même si des Gestionnaires de Versions tels que Git existent, cela résulte souvent en une certaine perte de temps, ou des situations gênantes.

Le MVC permet de séparer de manière nette, tous ces fichiers. De cette manière, il y a moins de risques de conflits. De plus, l’organisation du code est améliorée, puisqu’on peut déterminer plus facilement le fichier à modifier s’il y a besoin de corriger un bug, ou de faire une simple modification. Enfin, chacun peut traiter la partie qu’il maîtrise, sans se soucier du fonctionnement du reste de l’application.

Le Modèle

Cette partie est simple. Elle concerne tous les fichiers en rapport avec le stockage de données, et les traitements qui y sont liés (enregistrement en base, validation, etc…). On pourrait créer un dossier (ou package) “Model” et y mettre toutes les classes en rapport.

Exemples de classes qui se situeraient dans le Modèle :

• User : une classe avec les attributs “firstName”, “lastName”, etc…
• Group : une classe avec les attributs “users”, “label”, etc…
• UserManager : une classe avec les méthodes “addUser”, “removeUser”, etc…
• GroupManager: une classe avec les méthodes “addGroup”, “removeGroup”, etc…
• UserValidation : une classe avec une méthode “isUserValid”
• GroupValidation : une classe avec une méthode “isGroupValid”
• Etc…

Dans les exemples données ci-dessus, il serait judicieux de créer des sous-dossiers “Entity” (User, Group), “Manager” (UserManager, GroupManager), et “Validation” (UserValidation, GroupValidation), etc…

Vous avez probablement compris avec ces exemples que le modèle ne s’occupe réellement que des données et du traitement de ces données. Un expert en base de données peut donc réfléchir aux données nécessaires au fonctionnement de l’application, définir le type qui correspond le mieux (int, varchar, double, etc…), ainsi que la taille, et les contraintes (“firstName” entre 2 et 50 caractères, obligatoire, etc….).

Le Modèle constitue une base solide pour l’application, à vous de réaliser une analyse précise avant de vous lancer tête baissée dans le développement.

La Vue

Maintenant que nous disposons des classes permettant de stocker et de traiter les données de l’application, il serait intéressant de pouvoir les afficher. Il s’agit du Front-End, c’est-à-dire toute la partie qui sera visible pour les utilisateur (HTML, CSS, JavaScript, … en WEB), (XAML, Spring SDL, … en logiciel), etc…

Vous devez vous rendre compte que le MVC n’est pas qu’une question de classes, mais de fichiers en général. Les fichiers HTML par exemple ne sont pas des classes.

Ces fichiers doivent être développés en considérant que toutes les données dont elles ont besoin leurs sont fournies. Par exemple, la page qui liste les utilisateurs de l’application ne s’occupe pas de récupérer les utilisateurs, elle doit juste afficher ceux qui lui sont fournis (tous les utilisateurs du site, les membres d’un groupe, etc… ce n’est pas son rôle de déterminer les données à afficher, mais celui du Contrôleur).

Le Contrôleur

Nous avons maintenant tout ce qu’il faut pour pouvoir développer l’application. La Vue nous permet d’afficher des données, et le Modèle nous permet de récupérer, stocker, traiter des données. Il faut maintenant mettre tout cela en relation, car avec une Vue et un Modèle, on ne peut pas procéder à l’inscription d’un utilisateur, ou à l’envoie d’un e-mail de confirmation par exemple. De même, il faut fournir à la Vue les informations qu’elle doit afficher.

Le Contrôleur va définir tous les points d’entrés de notre application, communiquer avec le Modèle pour récupérer/modifier/traiter/… des données, puis les passer à la vue pour qu’elle les affiche. C’est un peu le chef d’orchestre de l’application.

Exemple pour l’affichage des informations d’un utilisateur :

Le MVVM

Le MVVM, ou Model View View-Model (Modèle Vue Vue-Modèle en français) est un patron d’architecture conçu par Microsoft. Comme vous pouvez l’imaginer, il ressemble beaucoup au MVC, à la différence du Contrôleur qui joue un rôle légèrement différent.

Le Modèle et la Vue ont le même rôle que dans le MVC. S’ils ne sont pas clairs, n’hésitez pas à relire les parties les concernant.

Le Vue-Modèle

Si cela peut vous aider, imaginez qu’il s’agit d’un contrôleur, sauf qu’à la différence de ce dernier, il est entièrement attaché à la vue. Dans un MVC, le contrôleur récupère les données depuis le modèle, et les communique à la vue. Dans le MVVM, le Vue-Modèle est un fichier/une classe, qui est liée au fichier/classe qui gère l’affichage.

Prenons par exemple un site internet. Si vous avez étudié JavaScript, vous savez que ce langage permet de modifier en temps réel la page HTML qui est affichée à l’utilisateur. Dans certains cas, vous aurez besoin d’un fichier JavaScript, pour une page uniquement, afin d’ajouter/supprimer dynamiquement des éléments dans une liste. On appel généralement ce type de fichier en .NET du code behind (c’est-à-dire du code qui est derrière l’affichage).

Dans une application .NET basée sur XAML par exemple, on trouvera un fichier C# caché derrière un fichier XAML. Le fichier XAML permet d’afficher des éléments, et le fichier C# permet de communiquer avec le Modèle, et de modifier dynamiquement le fichier XAML via ce qu’on appel le “Binding”.

Parlons d’un exemple un peu plus concret. Nous avons une application dont le but est de lister tous les messages postés par des utilisateurs. Voici ce que nous pourrions créer :

• Une classe Message (avec un attribut “title” et “text”)
• Une classe MessageManager (avec une méthode findAll() qui retourne tous les objets Messages de la base de données)
• Un fichier MessageListView (fichier HTML, ou XAML, etc…) qui affiche les objets Messages.
• Une classe MessageListViewModel qui modifie en temps réel les données affichée dans MessageListView

Au chargement de la page, MessageListView va afficher une liste de Messages. Cette liste de message est gérée par MessageListViewModel. Lorsqu’on rempli le champ “Nouveau message”, et qu’on valide le formulaire, une méthode de MessageListViewModel sera appelée. Cette méthode va récupérer les informations contenues dans le formulaire de MessageListView, créer un nouvel objet Message avec ces informations, et appeler la méthode “persist” de MessageManager pour enregistrer ce message. Enfin, il mettra à jour la liste des Messages de MessageListView.

Le N-Tiers

Avant d’expliquer ce patron d’architecture, laissez moi préciser que “Tiers” en anglais ne signifie par la même chose que “Tiers” en français (X sur 3). En effet, dans ce cas cela signifie “Niveau”, ou “Couches”, pour désigner un modèle avec plusieurs couches.

Le N correspond à un nombre, car on peut parler d’application à 2 niveaux (ou couches, ou tiers), 3 niveaux, 4 niveaux, etc… 

Qu’est-ce qu’un niveau ?

Un niveau est un ensemble applicatif, de fichiers, de classes, etc… Chaque niveau ne peut communiquer qu’avec le niveau inférieur, et le niveau supérieur. En théorie, il ne devrait pas y avoir de communication entre le niveau 1 et le niveau 3 par exemple, sauf en passant par le niveau 2.

Si on considère le MVC comme un patron N-Tiers, on pourrait définir 3 niveaux :

• La Vue
• Le Contrôleur
• Le Modèle

Car vous vous souvenez que la vue, qui serait tout en haut par exemple, ne communique pas directement avec le modèle, qui serait tout en bas. Tout cela passe par le contrôleur.

Exemple d’application 2-Tiers

Une application Web, composée d’une niveau “Client” et d’un niveau “Server”, représente une architecture 2-Tiers, c’est-à-dire sur 2 niveaux.

Dans ce type de système (Web), le client envoi une requête au serveur qui lui répond avec une réponse.

Le niveau Client représente le Front-End, ce qui est visible pour l’utilisateur, alors que le niveau Server représente le Back-End, ce qui est fait en arrière-plan.

L’intérêt n’est pas seulement en termes de maintenabilité, mais aussi d’évolutivité. Imaginez qu’on veuille maintenant créer l’application mobile. Il n’y aurait dans ce cas pas besoin de re-développer toute la logique du Back-End, car étant totalement séparée, elle pourrait être ré-utilisée. Seul l’affichage qui serait propre aux mobiles devrait être développé.

Exemple d’application 3-Tiers

Toujours basé sur l’exemple d’une application Web, on pourrait imaginer une troisième couche, qui concernerait la base de données. De cette manière, on pourrait aisément modifier le Système de Gestion de Base de Données (MySQL, MongoDB, etc…), sans toucher à la couche “Serveur”.

Jusqu’à combien de niveaux ?

Autant que vous voulez, tant que cela reste justifié. Vous pouvez très bien ajouter une couche “WebService”, une autre couche “Business”, etc… tout dépend des besoins de votre application, ou de vos applications 😉

Quel est l’intérêt ?

Cette architecture vous permet de factoriser votre code, afin de ne pas coder plusieurs fois la même fonctionnalité. Si chaque fonction est développée de manière unitaire, en respectant la responsabilité du niveau dans lequel elle se situe (accès aux données, affichage, etc…), chaque élément sera plus facilement maintenable, mais aussi réutilisable au maximum.

Pour aller plus loin

Les patrons d’architecture abordés dans ce cours sont relativement simplistes. Aujourd’hui, d’autres patrons plus poussés sont de plus en plus souvent utilisés. Je vous invite à lire les articles sur l’architecture logicielle pour aller plus loin.

Pour résumer

Patron d’Architecture : La meilleure solution connue à un problème d’architecture récurrent.

Patron MVC : Model View Controller (très utilisé).

Patron MVVM : Model View View-Model (surtout dans les applications Microsoft).

Patron N-Tiers : Architecture à plusieurs niveaux.