Organisation générale d une application qui utilise une BD relationnelle. Types d applications pour la persistance. Base de données préexistante?

Transcription

1 Types d applications pour la persistance Université de Nice Sophia-Antipolis Version 0.6 5/8/05 Richard Grin Organisation générale d une application qui utilise une BD relationnelle Richard Grin Objet-relationnel page 2 Base de données préexistante? Toutes les applications n ont pas une complexité qui nécessitent une architecture n-tiers On va décrire les grands modèles d applications qui utilisent une base de données relationnelle La conception de l application va sans doute être différente si la base de données est préexistante ou non Et si elle préexiste, est-ce que le développeur de l application peut en modifier la structure ou non? Richard Grin Objet-relationnel page 3 Richard Grin Objet-relationnel page 4 3 modèles 3 modèles d applications : n un modèle «procédural» n un modèle objet simple n un modèle objet avec utilisation d un outil de mapping Évidemment, ce découpage est très schématique Chacun de ces modèles peut utiliser ou non des passerelles pour isoler davantage le code qui gère la persistance Richard Grin Objet-relationnel page 5 1. Autour des procédures Pour les applications aux fonctionnalités les plus simples et pour un développement rapide Le plus souvent la base de données est préexistante L application est organisée autour de procédures qui accèdent directement à la base de données quand c est nécessaire Utilisation possible de procédures stockées pour encapsuler les scénarios des cas d utilisation Richard Grin Objet-relationnel page 6 1

2 Exemple La classe GestionEmploye contient la méthode ajouter(int matricule, String nom, ) qui ajoute un nouvel employé, en ajoutant une nouvelle ligne dans la base Elle contient une autre méthode double gettotaldept(int dept) qui renvoie le total des salaires pour un département, en lançant une requête SQL qui ramène le résultat On peut se passer de la classe Employe Richard Grin Objet-relationnel page 7 Ce modèle est limité On est dans ce cas très éloigné du modèle objet ; on ne profite donc pas de ses atouts : n héritage n polymorphisme n facilité de réutilisation des objets n relations entre objets n Quand l application se complexifie il est souvent difficile de l enrichir avec de nouvelles fonctionnalités et de réutiliser/partager du code Richard Grin Objet-relationnel page 8 2. Un modèle objet simple Le modèle étant simple, la correspondance entre les tables et les classes est le plus souvent bijective Chaque classe contient le code pour gérer la persistance des objets Le désavantage est que les classes métier sont trop liées au support de persistance utilisé Pattern appelé «active record» par Martin Fowler Exemple La classe Employe correspond à la table employe Elle contient la méthode d instance ajouter() (on pourrait l appeler ajoutetoidanslabase) qui ajoute une ligne dans la table EMPLOYE ; cette ligne contient les valeurs des attributs de l instance La classe contient aussi des méthodes sauvegarder() (ou modifier()), supprimer() Richard Grin Objet-relationnel page 9 Richard Grin Objet-relationnel page 10 Méthodes pour la recherche Elles peuvent être mises : n dans une classe qui se charge des recherches (un finder) n en static dans la classe métier qui correspond au type renvoyé n dans le cas particulier où le critère de recherche correspond à une des classes métier, la méthode peut être mise dans cette classe métier Exemple Une méthode qui recherche tous les employés d un département Choix 1 : List<Employe> rechercher(dept dept) dans la classe RechercheEmploye Choix 2 : static List<Employe> rechercher(dept dept) de la classe Employe Choix 3 : List<Employe> getemployes() de la classe Departement Richard Grin Objet-relationnel page 11 Richard Grin Objet-relationnel page 12 2

3 3. Un modèle objet complexe avec outil de mapping Pour les modèles objets complexes avec beaucoup d héritage et de relations entre classes le modèle «active record»se révèle vite difficile à implémenter et à maintenir Le plus efficace est alors de faire appel à un outil de mapping ou un framework pour automatiser la correspondance objetrelationnel Outils de mapping Ces outils permettent de décrire la correspondance objet-relationnel dans des fichiers des configuration ou par des annotations (introduites depuis le JDK 5) La persistance peut alors devenir presque transparente pour le développeur qui écrit le code Java Il est difficile d écrire soi-même de tels outils car ils sont très complexes Richard Grin Objet-relationnel page 13 Richard Grin Objet-relationnel page 14 Hibernate Hibernate est l outil de mapping le plus utilisé dans le monde Java Il permet de gérer la persistance des instances de n importe quelle classe Java Il utilise un gestionnaire de persistance, l introspection et l enrichissement de code à l exécution pour récupérer les valeurs des propriétés des objets et gérer leur persistance Autres possibilités JDO (Java ******) est une autre API qui offre des possibilités semblables à Hibernate Il utilise l enrichissement de code pendant la phase de compilation Il est aussi possible d utiliser la spécification EJB Richard Grin Objet-relationnel page 15 Richard Grin Objet-relationnel page 16 Frameworks (cadres) Ensemble de classes et ressources préexistantes que le développeur doit compléter Utilisation d une librairie : l exécution est dirigée par le code écrit par le développeur, qui fait appel aux classes de la librairie Utilisation d un framework : l exécution est dirigée par le framework qui fait appel au code écrit par le développeur EJB Le framework standard pour les applications Java d entreprise, EJB (Entreprise Java Beans), est fourni par J2EE, la version «d entreprise» de Java Il nécessite l utilisation d un serveur d application qui est un logiciel lourd On réservera l utilisation des EJB pour les grosses applications d entreprises Richard Grin Objet-relationnel page 17 Richard Grin Objet-relationnel page 18 3

4 EJB Les EJB sont des classes Java qui décrivent le comportement des objets métier Le développeur écrit le code lié aux fonctionnalités des objets métier, sans s occuper des services techniques (sécurité, distribution sur plusieurs machines, persistance, ) Le serveur d applications utilise ce code en pour y ajouter tous les services techniques indispensables au bon fonctionnement de l application Richard Grin Objet-relationnel page 19 EJB Entités Il existe plusieurs types d EJB Les EJB entités CMP (Container Management Persistence) correspond aux objets métier persistants Leur persistance entièrement prise en charge par le container d EJB fourni par le serveur d application Richard Grin Objet-relationnel page 20 Problèmes EJB entités 2 Les classes persistantes doivent hériter de certaines classes fournies par le framework Ça implique qu elles ne peuvent hériter d autres classes Le framework ne peut donc prendre en charge la persistance d objets des classes Java ordinaires (POJO : Plain Old Java Object) Il est aussi difficile, sinon impossible, d utiliser les classes persistantes en dehors du container, en particulier pour les tests Avantages EJB entités 2 L avantage d utiliser les EJB entités 2 est que la prise en charge est complète (sécurité, transaction, distribution, accès concurrents, ) et qu il est plus facile de maintenir le code lorsque l application monte en charge (plus grand nombre de connexions, distribution des serveurs sur plusieurs machines, ) Cet avantage ne compense qu en partie les problèmes liés à cette spécification Richard Grin Objet-relationnel page 21 Richard Grin Objet-relationnel page 22 EJB 3 EJB 3 revoit en grande partie les EJB entités Ils sont utilisés comme avec Hibernate (étudié dans la suite du cours) En particulier, les beans entités n ont plus à hériter de classes spéciales et peuvent être testés en dehors du serveur d applications La spécification n est pas encore officielle à la date d aujourd hui Passerelles Ces classes contiennent tout le code pour gérer la persistance Chaque table a une classe «passerelle» qui lui correspond Le reste de l application fait appel à elles pour gérer la persistance Facilite les changements de SGBD et/ou permet d alléger le code des classes métier Peuvent être utilisées avec les 3 modèles Richard Grin Objet-relationnel page 23 Richard Grin Objet-relationnel page 24 4

5 2 types de passerelle Une instance de passerelle par table (le plus fréquent) Une instance par ligne de table Le pattern DAO (Data Access Objects), très utilisé, correspond à une passerelle par table Exemple de passerelle La classe EmployeDAO gère la persistance des instances de la classe Employe et correspond à la table employe Elle contient la méthode ajouter(int matricule, String nom, ) La méthode prend en paramètre les informations sur l employé à ajouter car on a une seule instance de la classe EmployeDAO pour tous les employés Richard Grin Objet-relationnel page 25 Richard Grin Objet-relationnel page 26 Exemple de passerelle Avec une instance de passerelle par ligne, on aurait une méthode ajouter() car la passerelle aurait toutes les informations sur l employé auquel elle est liée Bibliographie Patterns of Entreprise Application Architecture de Martin Fowler Addison Wesley Richard Grin Objet-relationnel page 27 Richard Grin Objet-relationnel page 28 5