2009-08-18 5 views
0

Je construis un ensemble d'écrans CRUD pour un référentiel. Les objets membres sont suffisamment volumineux pour que je ne les charge pas en mémoire en même temps - comme lors de la génération de résultats de recherche. Puisque tout ce dont j'ai besoin pour les résultats de recherche est un couple de propriétés - par exemple, "name" et "id" - I pourrait simplement interroger la base de données sous-jacente - mais je ne veux pas contourner le référentiel, puisque nierait beaucoup de sa valeur.Modèle de référentiel: Stratégie pour l'inscription des membres

Les intros et les didacticiels de Repository Pattern que j'ai trouvés ne couvrent pas ce scénario. Ils se concentrent sur la sauvegarde/récupération/suppression d'un objet entièrement rempli à la fois.

Je connais bien le modèle Proxy pour les objets à chargement paresseux. Mais est-ce ainsi que les grands garçons le font? Y a-t-il une solution bien établie à ce problème?

Répondre

1

Si vous allez strictement par DDD, je pense que vos recherches devraient retourner des objets entièrement remplis. Mais parfois vous devez bander les règles.

Je peux vous dire quoi ne pas faire:

  1. Ne pas récupérer uniquement les données dont vous avez besoin et revenir encore des cas non entièrement peuplées de la classe d'entité. Cela peut facilement se transformer en catastrophe. Vous vous retrouvez avec des méthodes de requête différentes qui semblent renvoyer des entités entièrement remplies - mais en réalité cela dépendra de la méthode de requête qui a été appelée. Attendez-vous à la confusion.

  2. Ne lancez pas votre propre schéma d'initialisation paresseux. C'est difficile et sujet aux erreurs. Je l'ai fait une fois, et je peux dire sans risque que cela n'en valait pas la peine.

Alors, que reste-t-il? Mon vote consiste à saisir les données dont vous avez besoin et à créer une classe qui ne contient que les champs que vous avez l'intention de remplir, et à en renvoyer une liste. Maintenant, quiconque appelle votre fonction de recherche sait exactement ce qu'il obtient: un sous-ensemble des données réelles. Lorsque vous avez besoin de l'entité complète, vous devrez à nouveau cliquer sur la base de données.

Voici un exemple de ce que je veux dire en Java:

public class CakeRepository { 
    public List<CakeProjection> getCakesByManufacturer(String manufacturer); 

    public Cake getCake(long id); 

    ... 
} 

public class CakeProjection { 
    private long id; 
    private String cakeName; 

    ... 
} 
+0

Oui, oui, oui, tout est logique. Merci beaucoup. Maintenant, j'ai juste besoin de trouver un nom pour ces entités partielles. "Projection", hein ...? – Metaphile

0

Vous définissez des requêtes sur l'interface du référentiel qui récupèrent les données que vous recherchez.

Je pense que les grands garçons utilisent une couche ORM (comme Hibernate) et transmettent une requête définie à l'ORM.

+0

Donc, si une requête précise que je ne suis intéressé par les noms et les ID, mon dépôt peut retourner un ensemble d'objets avec la plupart de leurs propriétés défini sur NULL? – Metaphile

+0

la réponse acceptée me semble bonne. – mcintyre321

Questions connexes