Comment puis-je mettre en œuvre le motif de référentiel pour les modèles d'objets complexes?
Notre modèle de données comporte près de 200 classes qui peuvent être séparées à environ une douzaine de zones fonctionnelles. Cela aurait été agréable d'utiliser des domaines, mais la séparation n'est pas si propre et nous ne pouvons pas le changer.
Nous repensons notre DAL pour utiliser l'ensemble de l'entité et la plupart des recommandations que j'ai vues suggérez d'utiliser un motif de référentiel. Cependant, aucun des échantillons ne traite vraiment de modèles d'objet complexes. Certaines implémentations que j'ai trouvées suggèrent l'utilisation d'un référentiel-per-entité. Cela semble ridicule et non maintenu pour des modèles volumineux et complexes.
Est-il vraiment nécessaire de créer une unité de travail pour chaque opération et un référentiel pour chaque entité? Je pourrais me retrouver avec des milliers de cours. Je sais que cela est déraisonnable, mais j'ai trouvé très peu d'orientations mettant en œuvre un référentiel, une unité de travail et un cadre d'entité sur des modèles complexes et des applications commerciales réalistes.
Premièrement, vous courrez à travers toutes les entités que vous avez et que vous vous demandez:
Cela a-t-il un sens de persister cette entité seule?
Ce que je veux dire ici, est-ce que dans votre modèle d'objet, certaines entités sont probablement contenues dans d'autres dans une relation de détail de maîtrise. Si votre entité dépend fortement d'une autre, ne créez pas de référentiel pour cette entité seule car elle ne sera probablement pas persistée. Au lieu de cela, vous créerez un référentiel pour chaque classe mère et vous assurerez que les entités enfants et autres relations sont persistées en même temps.
Je n'aime pas comment ils ont mis en œuvre le motif de l'unité de travail dans le lien que vous avez fourni. Je vous suggère de faire quelque chose de plus sur ces lignes . Vous n'avez pas à définir une classe par référentiel. La même classe peut être utilisée pour chaque référentiel, chacune ayant sa propre instance de la classe UnitOfwork pour la durée de vie de l'opération. Vous pouvez également réutiliser la même unité de travail dans différents référentiels pour les modifications que vous souhaitez persister en même temps.
Peut-être devriez-vous avoir un coup d'œil à conception de domaine axée sur le domaine . Il recommande de regrouper vos objets dans des agrégats et de créer des référentiels uniquement pour l'entité racine de chaque agrégat. C'est une bonne façon de faire appel à un grand modèle d'objet complexe.
Vos différents domaines fonctionnels pourraient être contextes délimités . Il y a diverses techniques pour gérer les contextes bornés qui se chevauchent si la séparation entre elles n'est pas claire.
Quelle fondation théorique avez-vous trouvée pour la conception de la base de données "modèle de référentiel"? Je suppose qu'aucun. C'est une couche de complexité reposant sur une fausse prémisse: que la "couche de persistance" est quelque chose que vous devez être isolé. D'après ce que je peux dire, il joue à l'ignorance généralisée de programmation de principes de conception relationnels et à des pandres à une centralité présupposée de l'application OO Conception. Mais cela ne justifie pas son existence sur rationnelle, que seul théorique, motif.
Le seul chemin de la conception de la base de données n'a pas changé en 30 ans: analyser les données. Trouvez les clés et les contraintes et les relations de plusieurs à une. Concevez vos tables en fonction de la forme normale de Boyce-Codd. Utilisez des vues et des procédures stockées pour faciliter l'accès des données.
Non souhaitant, un SQL DBMS fournit une meilleure couche d'isolation que tout ce que le programmateur peut fournir. Il est vrai que, lorsque la base de données change, le SQL utilisé pour y accéder pourrait être modifié. Mais notez que c'est vrai peu importe s'il existe ou non une couche de médiation. Tant que l'application utilise des vues et des procédures stockées pour accéder au SGMS, les outils d'ingénierie SQL ordinaires indiquent lorsque des modifications apportées à la base de données sous-jacente invalident ces vues et des procédures stockées.
Il y a le défi, bien sûr. Une couche de médiation fournit l'illusion d'isolement et le confort au programmeur du code d'écriture, qu'il sait faire. La conception de la base de données d'apprentissage 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.
Quelqu'un de votre équipe s'opposera sans doute que la rédaction de SQL pour soutenir vos 200 classes est beaucoup de travail. Sans aucun doute. Mais au moins c'est tile travail. Si vous concevez une base de données en mimiquant votre OO Design, vous ferez également beaucoup de travail, une grande partie inutile et de la défaite la plupart de ce que le SGBD vous offre.
Par exemple, vous envisagez de réfléchir une unité de travail dans la base de données (sous forme de table ou de tables, je présume). nité de travail est un service intégré de la SGBD: begin transaction ... Mettre à jour la base de données ... commit transaction. Rien à modéliser, autre que la cartographie de vos classes aux tables de base de données dans SQL.
Votre question a été postée il y a 4 ans. Je réponds parce que c'était "mis à jour" d'une certaine manière récemment, indiquant que cela a toujours un intérêt pour quelqu'un. J'espère que ma réponse encourage le lecteur à appliquer la théorie relationnelle de base sur le problème au lieu d'adopter une solution de contournement inutile.