le développement en couches un petit historique quelles couches

1
Marie-pascale Delamare d’après http://www.pckult.net/blog/introduction-au-developpement-en-
couche-n-tier/ et http://morpheus.developpez.com/architecture/
LE DÉVELOPPEMENT EN COUCHES
UN PETIT HISTORIQUE
Les logiciels les plus fréquemment développés sont des logiciels à interface graphique permettant la gestion
d’un ensemble de données tel que les données des étudiants dans le cadre de notre projet. Ces logiciels
doivent pouvoir ajouter, supprimer et modifier les informations qu'ils sont censés gérer. Informations en
général stockées dans une base de données relationnelle.
Dans les anciens programmes de gestion, l’interface utilisateur prenait en charge toute la logique de
l’application, soit l'interface graphique, les traitements et les accès à la base de données. Les développeurs ont
très vite aperçu les limites de cette architecture. En effet un changement de base de données, par exemple,
impactait tout le code de l’application et obligeait à la redéployer sur tous les postes. La maintenance des
logiciels développés de cette manière coutait donc cher.
Très vite l'idée de développer en couches est apparue.
QUELLES COUCHES ?
Une application « en couche » est généralement composée d’au moins 4 couches :
 L’interface graphique (GUI, Graphic User Interface)
 La couche métier (BusinnessObjects)
 La couche d’accès aux données (DAL, Data Access Layer)
 La couche logique métier (BLL, Business Logic Layer)
On peut parfois en trouver une de plus la couche de référence qui contiendra les objets qui seront passées
d’une couche à l’autre.
Dans notre exemple : l’interface graphique contient nos deux formulaires frm_listeEtudiant et frm_unEtudiant.
La couche métier contient notre classe métier « Etudiant ». La couche logique métier contient notre classe
contrôleur. La couche accès aux données contient nos classes Dataset, DataTable et tableAdapter. Les classes
DataSet et DataTable relèvent en fait de la couche référence puisqu’elles sont en fait déconnectées de la base
de données et que leurs instances sont passées d’une couche à l’autre. La classe tableAdapter, elle relève
vraiment de la couche d’accès aux données, puisque c’est elle qui gère vraiment l’accès à la base de données.
DÉTAILS DES COUCHES
L’INTERFACE GRAPHIQUE
C'est la représentation de l'IHM (interfaces visuelles). Fini le code spaghetti, ici on fait juste de l'affichage,
aucun traitement ou définition. Exemple : afficher la liste des étudiants ou gérer un étudiant (d’où nos deux
formulaires).
LA COUCHE MÉTIER
Les objets métier correspondent à tous les objets spécifiques qui sont manipulés dans l’application. Dans notre
cas, nous allons manipuler des étudiants. Un étudiant, c’est un identifiant, un nom, un prénom, etc. Toutes ces
caractéristiques sont les propriétés de notre classe Etudiant.

2
Marie-pascale Delamare d’après http://www.pckult.net/blog/introduction-au-developpement-en-
couche-n-tier/ et http://morpheus.developpez.com/architecture/
Si on avait manipulé des produits, on aurait très certainement créé une classe Produit. Dans notre cas, nous
avons-nous-même écrit le code de notre classe. Etudiant. Généralement, on part du principe qu’une table dans
la base de données représente une classe. Et que chaque colonne de la table représente une propriété de la
classe. Si on avait eu 50 tables dans notre base de données, on aurait pu avoir besoin de 40 classes (certaines
tables ne représentent pas forcément une classe, comme par exemple les tables temporaires, les tables
système, etc.).
LA COUCHE ACCÈS AUX DONNÉES
C’est dans cette partie que vous va gérer tout ce qui concerne l’accès aux données. Il y a, dans cette couche,
plusieurs parties bien distinctes :
 Une partie pour tout ce qui concerne l’accès à la base de données
 Une partie pour tout ce qui concerne les requêtes sur la base de données
Dans notre cas, nous avons commencé par définir une source de données, source de données chargée de la
connexion à la base de données.
Puis nous avons rajouté dans notre classe EtudiantTableAdapter les requêtes nécessaires à l’application.
LA COUCHE LOGIQUE MÉTIER
Nous avons donc, d’un coté notre interface graphique et de l’autre notre couche métier alimentée par notre
couche d’accès aux données.
Il serait tout à fait possible de relier directement les 2. Cependant, comment ferait-on si on avait besoin
d’appliquer des règles valables pour tous les formulaires de notre application ou de gérer l’affichage de
messages d’erreur dans les formulaires en fonction des retours de la classe métier sans dupliquer ce code ? Où
mettre ce code ? Pas dans l’interface graphique, car il ne doit y avoir que ce qui concerne l’interface et aucun
code dupliqué. Dans la couche d’accès aux données ? Non, car cette couche ne traite que de l’accès aux
données.
La couche métier peut prendre en charge une partie de ce code, par exemple la vérification de la date de
naissance de l’étudiant et le retour d’un numéro d’erreur si cette date est située dans le futur.
Mais la gestion des messages d’erreur, par exemple va être prise en charge par une nouvelle couche, que l’on
appelle la couche logique métier. C’est le lien entre l’interface utilisateur et la couche métier.
Nos formulaires appelleront donc des méthodes de notre couche logique métier qui appellera des méthodes
de notre couche métier, qui appellera les méthodes de notre couche accès aux données.

3
Marie-pascale Delamare d’après http://www.pckult.net/blog/introduction-au-developpement-en-
couche-n-tier/ et http://morpheus.developpez.com/architecture/
ORGANISATION D’UN PROJET VB.NET DÉVELOPPÉ EN COUCHES AVEC ADO.NET
frm_1
frm_2
frm_3
Logique
Métier
Classe
métier
Accès aux
données
Les services d’une couche sont mis à
disposition de la couche supérieure. On
s’abstient alors lorsqu’on programme,
qu’une couche invoque les services
d’une couche plus basse que la couche
immédiatement inférieure ou plus
haute que la couche immédiatement
supérieure (chaque niveau ne
communique qu’avec ses voisins
immédiats sauf pour ce qui concerne la
couche référence).
Ceci explique les références que nous
avons mises en place entre nos
différents projets.
Vous avez fait du réseau en SI2, vous
avez étudié le modèle OSI, vous
comprenez maintenant que ce principe
de développement en couches est très
largement utilisé.
Référence

4
Marie-pascale Delamare d’après http://www.pckult.net/blog/introduction-au-developpement-en-
couche-n-tier/ et http://morpheus.developpez.com/architecture/
POURQUOI DÉVELOPPER EN UTILISANT LES COUCHES ?
Nous avons vu comment, d’un point de vue technique, nous pouvons mettre en place une application utilisant
les différentes couches. Mais une question reste toujours en suspens : «Pourquoi développer de cette façon ?».
En effet, jusqu’à maintenant, vous avez sans doute développé des applications, entièrement fonctionnelles,
sans utiliser cette technique. Alors pourquoi ? En fait, il y a plusieurs avantages à utiliser cette technique :
 La maintenance des données est indépendante du support physique de stockage
 La maintenance des traitements est simplifiée
 La gestion des traitements depuis la couche de présentation est facilitée
 Le travail en équipe est optimisé
 La migration d’un environnement graphique à un autre est relativement simple.
Lorsqu’on dit que le travail en équipe est optimisé, la raison est simple : alors qu’un des membres de l’équipe
travaille sur la couche d’accès aux données, un autre peut tout à fait travailler sur la couche métier ou sur
l’interface graphique sans perturber le travail de ses collègues.
De même, dans le cas d’une migration (d’interface utilisateur par exemple), là encore, la tâche est simplifiée.
Ainsi, inutile de re-développer tout ce qui a été fait jusqu’à maintenant, il suffit de modifier la couche
l’interface.