EnglishCommencer

L'accès aux données : DAO, ORM, annuaires

Isoler l'accès aux données derrière une couche dédiée : patron DAO, correspondance objet-relationnel, chargement paresseux et problème N+1, annuaire LDAP.

  • 26 cartes
  • 5 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation
  5. Comprendre

Quelques cartes du deck

  • DAO (objet d'accès aux données) : de quoi s'agit-il ?

    Voir la réponse

    Classe, derrière une interface, qui cache au reste du code comment une entité est lue et écrite dans le stockage.

    Le code métier appelle clientDao.trouver(7) sans savoir si la source est MySQL, PostgreSQL ou un fichier ; changer de stockage ne touche qu'une classe, et un faux DAO simplifie les tests.

  • Laquelle de ces méthodes n'a pas sa place dans l'interface ClientDao ?

    • double calculerRemise(Client c)
    • Optional<Client> trouverParEmail(String email)
    • List<Client> trouverParVille(String ville)
    • void supprimer(long id)
    Voir la réponse

    double calculerRemise(Client c)

    Un DAO lit et écrit des entités. Une règle de calcul comme la remise est de la logique métier : elle va dans un service. Les trois autres sont des lectures ou des écritures dans le stockage.

  • Avec un ORM, une … correspond à une table, un … à une colonne et une association à une ….

    Voir la réponse

    Avec un ORM, une classe correspond à une table, un attribut à une colonne et une association à une clé étrangère.

    Chaque instance correspond à une ligne, et son identifiant à la clé primaire. C'est cette table de correspondance que les annotations ou les fichiers de configuration décrivent.

  • CRUD : de quoi s'agit-il ?

    Voir la réponse

    Les quatre opérations de base sur une entité stockée : créer, lire, mettre à jour, supprimer.

    Un DAO les expose pour chaque entité. Elles correspondent aux ordres SQL INSERT, SELECT, UPDATE et DELETE, et aux méthodes HTTP POST, GET, PUT et DELETE d'un service REST.

  • Les classes métier d'une application contiennent des requêtes SQL ; passer de MySQL à PostgreSQL oblige à toucher 40 classes. Quelle est la cause et la solution ?

    • Les requêtes ne sont pas paramétrées ; il faut passer en requêtes préparées
    • L'accès aux données est éparpillé ; le regrouper derrière des DAO
    • Les tables manquent d'index ; il faut en ajouter avant de migrer
    • Les tables sont mal nommées ; il suffit de les renommer
    Voir la réponse

    L'accès aux données est éparpillé ; le regrouper derrière des DAO

    Quand le SQL est dans chaque classe, tout changement de stockage se propage partout. Derrière une interface DAO, seule l'implémentation change et le code métier reste intact. Requêtes préparées et index sont de bonnes pratiques, mais laissent le SQL éparpillé.

Réviser ce deck