- Patrons de conceptions pour la programmation orientée objet - Chaque problème de programmation = déjà rencontré par d autres informaticiens - Une solution existe généralement parmi les Design Patterns décrits dans la «littérature» - Des lectures pour approfondir le sujet: «Design Patterns GoF»
Dans le cas de l accès aux données, des programmeurs ont montré que le code le plus pratique est : - Une couche métier: objets simples (POJO en Java) correspondant aux tables de la base de données, avec attributs et getters/setters - Une couche DAO (Data Access Objects): classes contenant le code pour la connexion à la base de données, les requêtes SQL, et qui se charge d intégrer le résultat de ces requêtes dans les objets métiers delete) - Les classes DAO = méthodes CRUD (create, retrieve, update,
Exemple de couche métier : User - id: int - age: int - firstname: String - name: String 1 * DomesticAnimal - id: int - name: String - age: int public class User { public class DomesticAnimal { private int id; private int age; private String firstname; private String name; public Collection<DomesticAnimal> domesticanimals; public User() { public int getage() { return age; public void setage(int age) { this.age = age; private int id; private int age; private String name; private User user; public int getage() { return age; public void setage(int age) { this.age = age;
Couche DAO correspondant: UserDAO + create(user) : User + retrieveall() : Collection<User> + save(user) : User + update(user) : User DomesticAnimalDAO + create(domesticanimal) : DomesticAnimal + retrieveall(collection<domesticanimal>) : DomesticAnimal + save(domesticanimal) : DomesticAnimal + update(domesticanimal) : DomesticAnimal MySQLUserDAOImpl - connecttodatabase() : void + create(user) : User + retrieveall() : Collection<User> + save(user) : User + update(user) : User OracleUserDAOImpl - connecttodatabase() : void + create(user) : User + retrieveall() : Collection<User> + save(user) : User + update(user) : User OracleDomesticAnimalDAOImpl - connecttodatabase() : void + create(domesticanimal) : DomesticAnimal + retrieveall(collection<domesticanimal>) : DomesticAnimal + save(domesticanimal) : DomesticAnimal + update(domesticanimal) : DomesticAnimal
public interface UserDAO { public void create(user user); public void delete(user user); public void update(user user); public Collection<User> retrieveall(); public class OracleUserDAOImpl implements UserDAO { private Connection connecttodatabase() { try { Class.forName("oracle.jdbc.driver.OracleDriver"); catch (ClassNotFoundException e) { System.err.println("Erreur de chargement du driver " + e); return null; try { String url = "jdbc:oracle:thin:@neptune.ens:1521:master"; Connection c = DriverManager.getConnection(url, "scott", "tiger"); return c; catch (Exception e) { System.err.println("Erreur de connection " + e); return null; public void create(user user) { Connection connection = connecttodatabase(); try { Statement stmt = connection.createstatement(); String sql = "Insert into User(name,firstName, age) values(" + user.getname() + "," + user.getfirstname() + "," + user.getage() + ");"; stmt.execute(sql); catch (SQLException e) { System.err.println("Erreur dans l'enregistrement de l'utilisateur");
Conclusion : On respecte le principe d indépendance des couches Tout le code SQL est centralisé (simplifie la maintenance) On pourra ensuite manipuler avec simplicité les objets métiers dans le code (pour du calcul, de la présentation ) Si on change de SGBD, une seule couche à faire évoluer, le reste est toujours valable On peut facilement faire évoluer la couche métier Mais attention: la couche métier est intimement liée au schéma de la base de données, ils doivent évoluer ensemble!