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. 1 Marie-pascale Delamare d’après http://www.pckult.net/blog/introduction-au-developpement-encouche-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. 2 Marie-pascale Delamare d’après http://www.pckult.net/blog/introduction-au-developpement-encouche-n-tier/ et http://morpheus.developpez.com/architecture/ ORGANISATION D’UN PROJET VB.NET DÉVELOPPÉ EN COUCHES AVEC ADO.NET 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 frm_1 frm_2 Logique Métier Classe métier Accès aux données frm_3 3 Marie-pascale Delamare d’après http://www.pckult.net/blog/introduction-au-developpement-encouche-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. 4 Marie-pascale Delamare d’après http://www.pckult.net/blog/introduction-au-developpement-encouche-n-tier/ et http://morpheus.developpez.com/architecture/