Utilisons-nous le modèle de référentiel correctement?


14

Nous utilisons un tas de classes distinctes suffixées avec -repositorypour récupérer les données de la base de données; pour chaque table son propre référentiel.

Nous avons par exemple une customerrepositoryclasse qui a toutes sortes de méthodes pour récupérer les clients, et une vacancyrepositoryqui a toutes sortes de méthodes pour récupérer les postes vacants.

J'ai deux questions sur cette façon de faire:

  1. Que diriez-vous d'obtenir des données qui s'étendent sur plusieurs tables? Par exemple, j'ai un écran qui montre tous les clients qui n'ont pas encore créé de poste vacant. Une customerrepositoryméthode peut-elle utiliser les vacancyrespository, ou les deux référentiels renvoient-ils des résultats et existe-t-il une classe plus élevée dans la hiérarchie (appelons-la a dataservice) qui obtient les résultats des deux référentiels et les combine en un seul résultat?

  2. quelle logique un tel référentiel peut-il gérer?
    Je pense qu'il est OK d'implémenter le 'where active == true' dans un référentiel pour récupérer uniquement les enregistrements actifs, ou même cette logique simple devrait-elle être gérée par une classe plus élevée dans la hiérarchie (appelons-la a dataservice)?

L'exemple que je rencontrais maintenant est celui-ci:

Nous avons une liste de questions, qui contient une ou plusieurs questions.
La question peut avoir un résultat, qui est conservé dans un tableau séparé.
Ainsi, lorsque vous souhaitez récupérer le résultat total de la liste de questions, vous devez combiner les données du questionlisttableau, du tableau des questions et du questionstatustableau.

À l'heure actuelle, nous avons 3 référentiels différents pour ces tables.

Si je demandais questionlistrepositoryquel est le résultat total pour la liste numéro 12, il faudrait obtenir des données de deux autres référentiels et donc avoir une certaine logique, est-ce autorisé?

Ou existe-t-il un questionlistdataservicequi sait quels référentiels utiliser?

Une dernière chose: nos référentiels peuvent entraîner un IQueryableafin qu'un service appelant puisse facilement combiner les résultats, mais qu'en est-il lorsque ce n'est pas le cas, je ne pense pas que ce soit une bonne idée de récupérer tout le contenu des trois tables à partir du base de données.


1
Généralement, dans les accès à plusieurs tables, la table dominante est déterminée par la table de l'enregistrement qui doit exister avant que la requête ne la récupère. Dans LEFT OUTER JOIN, ce serait le premier tableau mentionné et dans RIGHT OUTER JOIN, ce serait le second.
Neil

Réponses:


15

Le référentiel renvoie des objets de domaine et est construit au-dessus des couches de mappage. Pour un domaine de domaine très simple, les objets et les tables de base de données peuvent être très similaires.

Si votre référentiel retourne toujours une représentation exacte de votre structure de données, il peut s'agir en fait de Table Data Gateway aka Data Access Object (DAO).

Exemple: votre base de données contient des tables pour la personne et l'adresse. Dans votre application, l'adresse de domaine n'est pas une entité en soi, c'est juste une propriété de Person. Dans ce cas, vous n'auriez pas PersonRepository et AddressRepository. Vous avez juste PersonRepository. Le domaine ne doit pas se soucier de la persistance des données du domaine. Ces responsabilités sont dans une couche derrière le référentiel.

D'après votre exemple, il semblerait que vous ayez réellement des DAO et que vous venez de les nommer Référentiels.


Ainsi, lors de la création d'un référentiel, je peux également avoir une passerelle de données de table un niveau plus profond, et nos référentiels sont en fait du TMD.
Michel

1
Vous pourriez, mais pesez le coût et les avantages. Ne vous laissez pas intimider pour garder les DAO et les référentiels séparés par le principe de la "superposition" de code. Faites ce qui est le plus lisible dans ce cas. La séparation et la couche d'abstraction résultante peuvent être utiles si vos référentiels ont tendance à faire beaucoup de recombinaison des données dans les DAO.
Mihai Danila
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.