Organisation de classes à l'aide du modèle de conception de référentiel

Question

J'ai commencé à mettre à niveau l'une de nos applications logicielles internes, écrites dans ASP.NET Web Forms, et migrées vers ASP.NET MVC.

J'essaie d'exploiter le modèle de conception du Repository pour mes classes, ce qui m'amène à ma question sur la quantité à mettre dans un dépôt.

Je les entités suivantes:

• Sujet
• Commentaires Sujet (sujet peut avoir plusieurs commentaires)
• révisions Sujet (À tout moment un sujet est édité, une révision est enregistrée)
• Sujet Abonnements (Permet aux utilisateurs de de s'abonner à des modifications pour un )

J'ai actuellement une interface pour ITopicRepository et une classe appelée TopicRepository qui gère tous les CRUD de base pour un sujet. Je me prépare maintenant à ajouter du code pour les commentaires, les révisions et les abonnements.

Je me demande si tout cela va dans le TopicRepository OU que je crée un référentiel pour chacune des entités, par exemple, TopicRevisionRepository et ainsi de suite.

Answer 1

Il existe une déconnexion assez substantielle entre la stratégie d'accès aux données MVC moyenne et la compréhension de la structure du référentiel basée sur le domaine.

La plupart des exemples que vous verrez pour ASP.Net MVC ne sont qu'une légère étape au-delà d'ActiveRecord, en utilisant des objets Repository par entité. Ce qu'ils implémentent actuellement est une sorte de passerelle de données de table, et utilise le mot Repository au lieu de Gateway.

Il n'y a rien de mal à cela pour beaucoup d'applications, et j'ai généralement commencé de nouvelles applications avec la même approche jusqu'à ce que je puisse prouver que j'ai besoin de quelque chose de différent. Toutefois, les principes de conception guidée par domaine, à partir desquels l'idée du référentiel est généralement empruntée, vous permettent d'identifier les racines agrégées et de consolider l'accès aux données pour ces entités enfants via le référentiel de la racine de l'agrégat.Cela vous permet de définir des limites autour des modifications d'état dans votre magasin de données et vous aide à appliquer des modifications transactionnelles, entre autres.

Édité pour ajouter: Dans votre exemple, il semble hautement improbable que vous modifiez l'un de ces objets enfants de manière isolée du parent, donc je serais tenté de dire qu'un "sujet" est une racine agrégée pour ton domaine.

Answer 2

À mon avis, il devrait aller dans son propre référentiel ...

Edit:

sert d'intermédiaire entre le domaine et les données couches de cartographie à l'aide d'une interface de collection comme pour l'accès domaine objets.

Repository Pattern

Cela permet si vous êtes intéressé à utiliser un référentiel générique comme this example ce qui signifie moins de code ...

Answer 3

En regardant le NerdDinner tutorial, ils semblent aller avec une respository par entité.

Quand on y pense, c'est logique. Il y aura des cas où vous voulez avoir le contrôle sur quand charger des sous-entités.

Answer 4

Je pense que cela dépend de la façon dont vous allez accéder à vos données. Les changements sont toujours à regarder un sujet avec ses commentaires et vice versa pour (32) éléments d'interface utilisateur Commentaires.

Par conséquent, votre sujet devient un Aggregate Root et vous n'avez besoin que d'un seul référentiel pour cette approche. Une chose à considérer est que si vous avez beaucoup de petites choses vous avez seulement besoin d'un accès très étroit pour aimer une liste d'options pour une liste déroulante, vous ne voulez vraiment pas de référentiel complet pour cela. Le problème est qu'une fois que vous aurez passé 20 entités, vous aurez 20 interfaces et 20 référentiels à considérer dans votre solution.

Il est très pragmatique de n'avoir que des dépôts pour vos racines agrégées et de garder ensemble d'autres référentiels de type valeur. Par exemple un DropdownlistRepository ou quelque chose.

Enfin, au stade de votre projet, les problèmes de performances n'ont pas d'importance et la récupération d'un graphique d'objet complet pour le "sujet" n'est probablement pas si mal que cela. Gardez les choses simples, si vous utilisez un mappeur ORM, il devrait être capable de gérer le sujet à chaque fois que vous en avez besoin avec toutes ses entités enfants chargées paresseusement.