Fabien Bézagu

Lorsqu'on crée une architecture basée sur le Domain Model, il semble courant d'utiliser des classes nommées XxxDao ou YyyRepository. Qu'on les appelle avec l'un ou l'autre terme, elles ont toujours plus ou moins la même interface, à savoir :

public interface IXxxDaoOrRepository
{
  IList <Xxx> GetAll();
  Xxx GetById(int);
  void Add(Xxx);
...
}

Un exemple d'utilisation basé sur le terme DAO est l'article (à lire) de Billy McCafferty.

Dans son livre ADDDP^[1], Jimmy Nilsson utilise quant à lui le terme Repository.

Partant du principe selon lequel deux termes différents ont des significations différentes, je me suis récemment posé la question suivante : à part le goût personnel, quelles sont les différences entre le terme Repository et l'acronyme DAO ? Voici mon sentiment...

Selon moi, un DAO ressemble à une couche ou à un filtre permettant d'accéder aux données. Lorsqu'un client utilise un DAO, il aura alors l'impression que son appel sera relayé à une autre entité (base de données, fichier xml, autre couche, etc...).

Lorsque j'essaie de visualiser une Repository (un entrepôt en français), je ne vois plus une couche plate mais plutôt une boîte, un conteneur qui se suffit à lui-même ou du moins qui masque complètement les secrets de son implémentation.

Même si je comprend qu'on puisse préférer le terme DAO, il est clair que, dans mon approche actuel, ma préférence va vers le terme Repository qui me semble plus dans l'esprit du DDD.

Edit du 16/02/08 : plus d'un an après avoir écrit ce billet, je me rend compte que, même si j'avais "senti" la différence entre ces deux concepts que sont la DAO et la Repository, je ne voyais qu'une différence de nommage. Aujourd'hui, et notamment après la lecture DDD et à la lumière de mon expérience, je comprend pourquoi j'avais raison de penser que c'était différent et la raison principale est la suivante : la Repository est un concept du modèle du domaine, pas la DAO.