Que doit vraiment faire un référentiel?

J'ai beaucoup entendu parler du modèle de référentiel, mais je ne comprenais pas vraiment ce qu'un référentiel devrait vraiment faire. Quand je dis "ce qu'un dépôt devrait vraiment faire", je suis principalement préoccupé par les méthodes qu'il devrait fournir. Par exemple, un référentiel devrait-il vraiment fournir des méthodes CRUD, ou devrait-il fournir un autre type de méthode?

Je veux dire, les référentiels doivent-ils contenir une logique métier, ou doivent-ils simplement contenir la logique pour communiquer avec le magasin de données et gérer les entités à enregistrer ou à charger?

J'ai également entendu dire que les référentiels sont des unités de persistance pour les agrégats. Mais comment est-ce? Je n'arrive pas à comprendre comment cela fonctionne dans la pratique. Je pensais que nous devrions avoir une seule interface IRepositoryqui contient les méthodes CRUD, puis pour toute entité, l'implémentation contiendrait simplement la logique pour enregistrer et récupérer ce type dans le magasin de données.

Eh bien, vous pouvez voir un bon exemple dans Spring Data Framework qui est basé sur le concept de référentiels.

Là, vous verrez que les référentiels ne traitent que du magasin de données et contiennent rarement une logique métier (ceci est réservé à la couche de service). Ainsi, par exemple, vous jetez un œil à leur conception, vous verrez qu'ils ont une interface CRUDRepository qui expose des méthodes pour créer, détruire et récupérer des entités (entre autres). Il existe également un PagingAndSortingRepository qui ajoute des fonctionnalités supplémentaires pour cela, le tri et la pagination des résultats, etc., etc.

Donc, ce cadre est peut-être un bon endroit pour étudier une bonne conception de référentiel.

Pour autant que je sache, bon nombre des concepts mis en œuvre par Spring Data Framework proviennent d'un grand livre intitulé Domain-Driven Design: Tackling Complexity in the Heart of Software , le livre a une section entière dédiée à la conception de référentiels.

Vous pourriez envisager d'en obtenir une copie.

Un petit extrait du livre explique:

Le modèle REPOSITORY est un cadre conceptuel simple pour encapsuler ces solutions et ramener notre objectif de modèle.

Un REPOSITORY représente tous les objets d'un certain type comme un ensemble conceptuel (généralement émulé). Il agit comme une collection, sauf avec une capacité d'interrogation plus élaborée. Les objets du type approprié sont ajoutés et supprimés, et la machinerie derrière le REPOSITORY les insère ou les supprime de la base de données. Cette définition rassemble un ensemble cohérent de responsabilités pour fournir un accès aux racines des AGRÉGATS du début du cycle de vie jusqu'à la fin.

Les clients demandent des objets au REPOSITORY à l'aide de méthodes de requête qui sélectionnent des objets en fonction de critères spécifiés par le client, généralement la valeur de certains attributs. Le REPOSITORY récupère l'objet demandé, encapsulant le mécanisme des requêtes de base de données et le mappage des métadonnées. REPOSITORIES peut implémenter une variété de requêtes qui sélectionnent des objets en fonction des critères requis par le client. Ils peuvent également renvoyer des informations récapitulatives, telles qu'un décompte du nombre d'instances répondant à certains critères. Ils peuvent même renvoyer des calculs récapitulatifs, tels que le total de tous les objets correspondants d'un attribut numérique.

Un REPOSITORY soulage un énorme fardeau du client, qui peut maintenant parler à une interface simple et révélatrice d'intentions, et demander ce dont il a besoin en termes de modèle. Pour prendre en charge tout cela, il faut beaucoup d'infrastructure technique complexe, mais l'interface est simple et conceptuellement connectée au modèle de domaine.

Donc:

Pour chaque type d'objet qui nécessite un accès global, créez un objet qui peut fournir l'illusion d'une collection en mémoire de tous les objets de ce type. Configurez l'accès via une interface globale bien connue.

Fournissez des méthodes pour ajouter et supprimer des objets, qui encapsuleront l'insertion ou la suppression réelle des données dans le magasin de données. Fournissez des méthodes qui sélectionnent des objets en fonction de certains critères et renvoient des objets ou des collections d'objets entièrement instanciés dont les valeurs d'attribut répondent aux critères, encapsulant ainsi la technologie de stockage et de requête réelle. Fournissez des REPOSITOIRES uniquement pour les racines AGRÉGÉES qui ont réellement besoin d'un accès direct. Gardez le client concentré sur le modèle, en déléguant tout le stockage des objets et l'accès aux REPOSITOIRES.

Il ne devrait ni fournir une interface CRUD directe ni faire de logique métier. Il sert de médiateur entre la logique métier et la base de données. L'interface doit être en termes de logique métier mais ne pas exécuter la logique métier elle-même, plus comme une primitive de logique métier. Par exemple, disons que vous alliez créer un système de messagerie, vous avez des utilisateurs et des messages. Votre référentiel fournirait des opérations CRUD de base pour les utilisateurs et les messages, mais il fournirait également des vues filtrées de messages tels que GetUsersNewMessages (utilisateur) ou GetSearchedMessages (utilisateur, searchTerms).

L'idée est que le référentiel masque la façon dont le stockage est implémenté et fournit une interface propre qui permet un accès flexible et rapide aux données. Garder les opérations en termes de haut niveau de ce qui devrait se produire plutôt que de la façon dont vous avez plus de flexibilité pour les implémenter de la manière la plus appropriée pour le magasin de support sous-jacent.