DAO et ORM sont-ils compatibles ?

Les architectures modernes sont typiquement découpées en couches représentant des services concentriques de plus en plus haut niveau :

• Accès aux données (couche de persistance ou DAO, l’objet de ce billet),
• Traitements métiers,
• Présentation à l’utilisateur ou exposition à des systèmes tiers.

Les bonnes pratiques imposent que chacune de ces couches soit représentée par une interface exprimant le service qu’elle rend et masquant la façon dont elle est implémentée. Leur respect permet d’obtenir des architectures modulaires et faiblement couplées, facilitant le test et la maintenance des applications.
Pourtant, les ORMs remettent en cause ce schéma.

La couche de persistance

Le service demandé à une couche de persistance est parfaitement exprimé par l’acronyme CRUD (Create, Retrieve, Update, Delete), c’est-à-dire que l’on souhaite pouvoir sauvegarder, récupérer, mettre à jour et supprimer les données que l’application manipule.
L’interface typique d’une couche DAO ressemble donc à :

1. public interface ClientDao
2. {
3. public Client save(Client client);
4. public Client update(Client client);
5. public void delete(Client client);
6. public Client getClient(ClientId id);
7. public Collection<Client> getAllClients();
8. }

Constatez que cette interface est suffisamment générique pour ne laisser transparaître aucun détail technique, et peut ensuite être implémentée facilement de différentes façons : écriture dans un fichier plat ou XML, insertion en base de données, sauvegarde sur un système distant, sauvegarde en mémoire…

DAO et bases de données : le problème Hibernate

Les bases de données suivent depuis longtemps le modèle CRUD ; les instructions SQL INSERT, SELECT, UPDATE, DELETE en sont une transposition directe. Il est donc très simple d’implémenter une couche DAO via de simples appels JDBC basiques.
Tout était bien dans le meilleur des mondes, jusqu’à l’apparition des frameworks de mapping objet-relationnel (ORM), Hibernate en tête. Sous couvert de simplifier la vie du développeur (ce qui reste à démontrer), ils apportent une sémantique tout à fait différente et largement incompatible avec le système CRUD. En cause, la notion de cycle de vie des objets manipulés (transient / attaché / détaché), qui doit être géré manuellement par le développeur.
S’il apporte des fonctionnalités puissantes (mise à jour automatique, gestion de grappes d’objets…), ce système a une forte tendance à transpirer dans les couches supérieures – souvent même jusqu’à la couche de présentation, ce qui est une hérésie totale du point de vue architectural (cf. le pattern “open session in view“).
Exit donc le pattern CRUD. Exit aussi l’interface DAO générique indépendante de l’implémentation : les couches supérieures devant gérer finement le cycle de vie des objets, il est indispensable qu’elles puissent accéder aux APIs bas niveau du framework de persistance : persist, merge, delete, saveOrUpdate, lock…

DAO par ORM : isolation plutôt que découplage

Si la couche DAO n’est plus découplée des couches supérieures, est-elle encore utile ? Si son interface n’est qu’un simple miroir des APIs de l’implémentation sélectionnée, à quoi sert-elle ? Ne serait-il pas plus simple de reconnaître cet état de fait et de supprimer la couche DAO lorsqu’on utilise un framework d’ORM ?
A cette question qui mérite réflexion, je préfère apporter une réponse nuancée.
Certes, le découplage est cassé ; mais la couche DAO conserve une utilisé pratique : elle permet d’isoler une partie du code technique spécifique (requêtes HQL / SQL, Criterions, Transformers…) dans des packages bien définis, et de garder l’apparence d’une architecture en couches standard.

Conclusion

Lors de la mise en place d’une pile technique, il faut savoir jeter un regard critique sur les différentes technologies disponibles sur le marché, et déterminer si leurs forces et faiblesses sont acceptables dans le cadre du projet. En particulier, il faut résister aux sirènes du “standard” (Spring/Hibernate/Struts par exemple) et ne pas hésiter à faire ses propres choix argumentés.
Cet article avait notamment pour but de vous faire prendre conscience que les ORMs ne sont pas des outils magiques, et qu’ils imposent de fortes contraintes sur l’architecture (en plus d’une certaine complexité), pouvant mener à des difficultés de testabilité ou de maintenance.