Quel fondement théorique avez-vous trouvé pour la conception de la base de données "Modèle de référentiel"? Je suppose que non. C'est une couche de complexité reposant sur une prémisse bidon: que la "couche de persistance" est quelque chose dont vous devez être isolé. D'après ce que je peux en dire, cela joue sur l'ignorance généralisée de la programmation des principes de conception relationnelle, et sur une centralité présupposée de la conception OO de l'application. Mais il ne justifie pas son existence pour des raisons rationnelles, et encore moins théoriques.
Le One True Path to design de base de données n'a pas changé depuis 30 ans: analysez les données. Trouvez les clés, les contraintes et les relations plusieurs-à-un. Concevez vos tables selon la forme normale de Boyce-Codd. Utilisez des vues et des procédures stockées pour faciliter l'accès aux données.
Si peu aimé qu'il soit, un SGBD SQL fournit une meilleure couche d'isolation que tout ce que le programmeur peut fournir. Il est vrai que lorsque la base de données change, le SQL utilisé pour y accéder peut devoir changer. Mais notez que cela est vrai, qu'il y ait ou non une couche de médiation . Tant que l'application utilise des vues et des procédures stockées pour accéder au SGBD, les outils d'ingénierie SQL ordinaires indiquent quand les modifications apportées à la base de données sous-jacente invalident ces vues et procédures stockées.
C'est là que réside le défi, bien sûr. Une couche de médiation donne l'illusion de l'isolement et le confort au programmeur de l'écriture de code, qu'il sait faire. Apprendre la conception de bases de données et SQL nécessite d'apprendre quelque chose de nouveau. La plupart des gens préfèrent mourir que de penser, et beaucoup réussissent.
Un membre de votre équipe objectera sans doute que l'écriture de SQL pour prendre en charge vos 200 classes représente beaucoup de travail. Sans aucun doute. Mais au moins, c'est un travail utile . Si vous concevez une base de données en imitant votre conception OO, vous ferez également beaucoup de travail, en grande partie inutile, et vaincrez la plupart de ce que le SGBD vous offre.
Par exemple, vous envisagez de refléter l'unité de travail dans la base de données (sous forme de table ou de tables, je présume). Unité de travail est un service intégré du SGBD: begin transaction
... base de données de mise à jour ... commit transaction
. Rien à modéliser, à part le mappage de vos classes aux tables de base de données en SQL.
Votre question a été publiée il y a 4 ans. Je réponds parce qu'il a été "mis à jour" d'une manière ou d'une autre récemment, ce qui indique que cela intéresse toujours quelqu'un. J'espère que ma réponse encourage le lecteur à appliquer la théorie relationnelle de base au problème au lieu d'adopter une solution de contournement inutile.