Architecture 3 tiers

Introduction

Première chose avant de commencer le travail technique proprement dit : un peu d'architecture logicielle.

Une bonne architecture logicielle aujourd'hui passe par un modèle multicouche.

L'accès, l'enregistrement et la gestion des données dans la base de donnée est une première de ces couches, qu'on appellera la couche donnée.

L'exploitation de ces données, l'intelligence des applications qui se reposeront dessus sont dans la couche métier. On parlera aussi d'API ou de framework.

Enfin tout ce qui concerne l'affichage graphique et les interactions avec les utilisateurs sont dans la couche interface.

Les explications qui suivent ont pour objectif de détailler et d'expliquer le pourquoi de cette architecture.

Vous noterez que le schéma est inversé par rapport à l'ordre dans lequel j'ai présenté les couches. Traditionnellement, les données sont dans la couche basse et l'interface dans la couche haute, mais il est plus facile d'expliquer ces concepts en commençant par la couche basse...

Pour bien appréhender le concept et l'utilité de ce modèle en couche, voici un exemple d'architecture avec plusieurs sources de donnée et plusieurs interfaces, autour d'un unique framework.

Les sources de données peuvent être par exemple deux bases de données distinctes.

Pour les interfaces on peut imaginer un site web et un service windows (inspiré d'un cas réel).

La couche donnée

Une couche donnée, pourquoi faire ?

Cette couche contient l'ensemble des I/O (Input/Output : les entrées et sorties de donnée) des applications qui vont s'appuyer sur le framework. Il peut s'agir d'accès à une base de donnée, dans un fichier XML, de lecture/écriture sur un périphérique spécifique, etc.

Cette partie est séparée de la couche supérieur, la couche métier, car cette dernière se doit d'être indépendante des choix techniques mis en oeuvre.

Imaginez que vous travaillez sous SQL Server, et que du jour au lendemain la licence triple de prix ou que le produit s'arrête. Si l'architecte à bien séparé les couches, l'impact est minime : il suffit de recoder la partie d'accès aux données. Dans le cas contraire, l'équipe technique va souffrir.

Imaginez que votre application utilise un scanner de code-barre pour identifier des produits. Si votre commercial se fâche avec son fournisseur et décide de changer de matériel, une couche donnée vous évitera de remettre en question toute vos applications.

Une couche donnée : ça contient quoi ?

Cette couche est généralement divisée en deux sous-couches distinctes : une couche procédure stockée et une couche d'accès aux donnée.

La couche procédure stockée permet de requêter les tables composant l'application et de les remonter de façon très performante en utilisant la variante du langage SQL intégrée au SGBD. Si votre application fonctionne à partir de SQL généré par votre serveur, alors cette couche n'existe pas. Dans ce cas, la plupart du temps, cette logique de requétage sera mélangée à la couche d'accès aux données, ce que je déconseille.

L'autre sous-couche est donc la couche d'accès aux données. Celle-ci contient la logique d'accès au SGBD et le code permettant d'envoyer les requêtes, de remonter les données, de les convertir dans le langage de travail et de les mettre en forme pour une exploitation par la couche du dessus.

La couche métier

Une couche métier, pourquoi faire ?

Le concept de couche métier est le plus compliqué à appréhender. En effet, si on a les données dans la base, et qu'on veut les afficher, pourquoi s'encombrer d'une couche intérmediaire ?

Parmi les bonnes réponses, je citerai "parce que c'est propre", "pour s'abstraire de la manière d'accéder au données", "pour l'évolutivité", "pour la maintenabilité", etc.

La couche métier et la sécurité

Lorsque votre framework doit être utilisé par plusieurs développeurs, l'utilisation d'une couche intermédiaire permet d'ajouter des sécurités pour éviter qu'une ligne de code malencontreuse fasse planter votre application ou détruise des données par inadvertance.

Exemple : avant de créer une entrée dans une table, je vérifie la validité des paramètres.

La couche métier et l'évolutivité

L'abstraction fournie par la couche métier vous permet d'enrichir vos tables sans modifier négativement les objets existants, elle vous permet de séparer fonctionnellement les erreurs de calculs avec les erreurs d'accès à la base. Elle permet de rassembler des informations contenues dans plusieurs tables en un seul objet lorsque cela a du sens.

Exemple : la table utilisateur et la table adresse sont remontées ensemble dans le seul objet 'Utilisateur'.

La couche métier et l'interopérabilité

Une fois votre couche métier codée et fonctionnelle, qu'est ce qui vous empêche de l'utiliser dans une application web ? une application client lourd ? Une application embarquée ? Un service Windows ? Rien, et c'est l'avantage principal, à mon sens, de l'architecture 3-Tiers : faire une API interopérable sans même s'en rendre compte.

Une couche métier : ça contient quoi ?

Des classes, tout simplement.

Dans de nombreux projets, ces classes étaient construites à partir d'objets intermédiaires (DataSet, ...) remontés de la base de donnée.

Récemment, dans un gros projet, j'ai mis en place des objets intermédiaires très légers (conteneurs de donnée), et ces conteneurs étaient encapsulés dans les objets de la couche métier dans leur unique constructeur. Cette approche était très performante, même si elle oblige à coder un objet intermédiaire.

La couche interface

Une couche interface : pourquoi faire ?

Saisir et exploiter les informations du système, bénéficier d'un service ou exposer des fonctionnalités du framework à une exécution automatique.

Quelques types d'interfaces possibles :

• Un site web
• Une application client lourd
• Un service windows
• Un service web

Une couche interface : ça contient quoi ?

Il y a trop de réponses possibles ici pour entrer dans le détail dans un simple post sur un blog. Pour simplifier : ça dépend de l'interface choisie. Chaque type d'interface que j'ai cité plus haut fonctionne avec des mécanismes très différents. Il y a matière à écrire un livre sur chacun.

Inutile de perdre ici de l'énergie : je détaillerai en temps et en heure la manière très spécifique d'architecture une interface web en utilisant le framework Castle.