Objet d'accès aux données
Cet article est une ébauche concernant l’informatique.
Pour les articles homonymes, voir DAO.
Un objet d'accès aux données (en anglais data access object ou DAO) est un patron de conception (c'est-à-dire un modèle pour concevoir une solution) utilisé dans les architectures logicielles objet.
Utilisation
[modifier | modifier le code]Les objets en mémoire vive sont souvent liés à des données persistantes (stockées en base de données, dans des fichiers, dans des annuaires…). Le modèle DAO propose de regrouper les accès aux données persistantes dans des classes à part, plutôt que de les disperser. Il s'agit surtout de ne pas écrire ces accès dans les classes "métier", qui ne seront modifiées que si les règles de gestion métier changent.
Ce modèle complète le modèle MVC (modèle-vue-contrôleur), qui préconise de séparer dans des classes les différentes problématiques :
- des vues : charte graphique, ergonomie
- du modèle : cœur du métier
- des contrôleurs : tout le reste ; l'enchaînement des vues, les autorisations d'accès…
Avantages et inconvénients
[modifier | modifier le code]L'utilisation de DAO permet de s'abstraire de la façon dont les données sont stockées au niveau des objets métier. Ainsi, le changement du mode de stockage ne remet pas en cause le reste de l'application. En effet, seules ces classes dites "techniques" seront à modifier (et donc à re-tester). Cette souplesse implique cependant un coût additionnel, dû à une plus grande complexité de mise en œuvre.
Exemple en Java
[modifier | modifier le code]Voici un exemple concret d'implémentation du pattern DAO en Java qui illustre la séparation entre la logique métier et l'accès aux données.
Une classe métier :
public class Client {
private int id;
private String name;
// Getters et setters
public int getId() { return id; }
public String getName() { return name; }
// Méthodes métier
public void contact(Client otherClient) { ... }
...
}
Client représente l'objet métier qui contient uniquement les données et le comportement liés au concept de client, sans aucune logique d'accès aux données.
Une classe technique :
public interface ClientDAO {
Client setName(int id, String newName);
List<Client> findAll();
...
}
Permet de définir le contrat pour toutes les opérations d'accès aux données concernant les objets Client.L' abstraction permet d'implémenter différentes stratégies d'accès aux données.
Implémantation MySQL :
public class ClientDAOMySQL implements ClientDAO {
private Connection connexion;
@Override
public List<Client> findAll() {
List<Client> clients;
// Utilisation de la syntaxe SQL pour récupérer tous les clients
// SELECT * FROM clients
// ...code d'exécution de la requête...
return clients;
}
@Override
public Client setName(int clientId, String newName) {
// Utilisation de la syntaxe SQL pour mettre à jour le nom
// UPDATE clients SET name = ? WHERE id = ?
// ...code d'exécution de la requête...
Client updatedClient;
// Code pour récupérer le client mis à jour depuis la base de données
// Par exemple : SELECT * FROM clients WHERE id = clientId
return updatedClient;
}
...
}
Implémantation MongoDB :
public class ClientDAOMongoDB implements ClientDAO {
private MongoCollection<Document> collection;
@Override
public List<Client> findAll() {
List<Client> clients;
// Utilisation de l'API MongoDB pour récupérer tous les documents
// collection.find()
// ...code d'exécution de la requête...
return clients;
}
@Override
public Client setName(int clientId, String newName) {
// Utilisation de l'API MongoDB pour mettre à jour un document
// collection.updateOne(Filters.eq("_id", clientId), Updates.set("name", newName))
// ...code d'exécution de la requête...
Client updatedClient;
// Code pour récupérer le client mis à jour depuis la base de données
// Par exemple : collection.find(Filters.eq("_id", clientId)).first()
return updatedClient;
}
...
}
Il est important que cette classe cache complètement d'où viennent les données : elle doit donc renvoyer des objets métier (et non un curseur, un enregistrement…).
public class DAOFactory {
public enum TypeBase { MYSQL, MONGODB }
public static ClientDAO getClientDAO(TypeBase type) {
switch (type) {
case MYSQL: return new ClientDAOMySQL();
case MONGODB: return new ClientDAOMongoDB();
default: throw new IllegalArgumentException("Type non supporté");
}
}
}
Fournit un moyen de créer l'implémentation DAO appropriée sans que le client ne connaisse les détails de l'instanciation. Cela permet de changer facilement de système de stockage sans modifier le reste du code.
Une classe gestionnaire d'objets :
public class ClientManager {
private ClientDAO clientDAO;
public ClientManager(DAOFactory.TypeBase typeBase) {
this.clientDAO = DAOFactory.getClientDAO(typeBase);
}
public void displayAllClient() {
List<Client> clients = clientDAO.findAll();
System.out.println("clients:");
for (Client client : clients) {
System.out.println("- " + client.getName());
}
}
public Client setClientName(int idClient, String newName) {
return clientDAO.setName(idClient, newName);
}
}
Il se concentre uniquement sur les opérations métier à effectuer avec ces données.
Exemple d'utilisation :
public static void main(String[] args) {
ClientManager clientManager =
new ClientManager(DAOFactory.TypeBase.MYSQL); // Ou DAOFactory.TypeBase.MONGODB
clientManager.displayAllClient();
Client client = clientManager.setClientName(1, "Dupont");
System.out.println("Client updated: " + client.getName());
}
On retrouve bien ici une structure de code qui ne change pas si on change de stockage !
Types d'accès aux données
[modifier | modifier le code]Il peut exister autant de types de DAO que de moyens de persistance des données.
- Fichiers : VSAM, binaires, XML…
- Base de données : relationnelles (cf. mapping objet-relationnel) ou autres.
- Annuaires LDAP, Active Directory…
Des bibliothèques logicielles sont d'ailleurs conçues spécifiquement pour prendre en charge ces aspects.
