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.