2010-11-19 44 views
2

Par exemple:Les objets domain peuvent-ils appeler d'autres mappeurs de données? (Zend Framework)

J'ai un utilisateur qui a 10 Widgets. Parallèlement à cela, j'ai un gestionnaire qui gère 5 de ces widgets.

Je veux récupérer les Widgets de l'utilisateur géré par un gestionnaire spécifié. J'ai donc créé une fonction dans mes WidgetMapper appelés fetchUsersManagedWidgets ($ USERID, ManagerID $) qui interroge le db pour les 5 widgets et cartes un tableau d'objets Widget.

Je sais que des objets de domaine ne sont pas censés être au courant de leurs cartographes, mais puis-je créer une fonction dans le modèle de l'utilisateur qui appelle une fonction de la WidgetMapper?

par exemple. Ou est-ce une voie à sens unique, et les objets de domaine ne devraient jamais appeler des fonctions de mappeur?

Répondre

1

Motif en général sont une idée de la façon dont vous pouvez résoudre un problème commun. Ils ne sont ni "obligés de le faire de cette façon" ni "tout le reste est mauvais". En fait, il y a même a name pour une décission ne suivant pas les modèles intentionnels. D'après ce que j'ai pu voir, les gens ont tendance à penser que «une table db est un domaine, donc chaque table db a besoin d'un modèle et d'un mappeur». Dans votre cas, je suppose que vous avez trois tables: les utilisateurs, les widgets et la table contenant la relation n: m entre les deux (je l'appellerai userwidgets).
L'userwidgets fait vraiment partie du modèle utilisateur et n'a pas de modèle/mappeur propre. Il fait et non partie du modèle de widget. Pour résoudre ces ids de widget dans le usermodel ont besoin du mapper de widget bien sûr qui résulte dans le problème que vous décrivez.
Il y a probablement beaucoup de façons de résoudre ce problème, je suppose simplement un défaut mappeur qui est réinscriptible:

Class UserModel 
{ 
    $_widgetMapper = null; 

    public function getWidgetMapper() 
    { 
     if(null === $this->_widgetMapper) 
     { 
      $this->setWidgetMapper(new DefaultWidgetMapper()); 
     } 
     return $this->_widgetMapper(); 
    } 

    public function setWidgetMapper($mapper) 
    { 
     // todo: make sure it's a mapper of the correct type 
     $this->_widgetMapper = $mapper; 
    } 
} 

Si vous ne souhaitez pas utiliser la valeur par défaut de widgets mappeur il vous suffit de mettre en avant accéder aux widgets de l'utilisateur (ils doivent être chargés à la demande).

+0

Tu as raison j'ai une table UserWidgets avec n: m relation. Ce qui m'amène à une question de suivi. Si userwidgets n'a pas son propre modèle/mappeur, quel mappeur dois-je utiliser pour enregistrer la relation avec la base de données? Je suis tenté de dire qu'une fonction dans le UserMapper appelée saveUserWidgets ($ user, $ widgets) est-elle correcte? – Craig

+0

@craig: Oui, je l'ajouter à la UserMapper en premier lieu. A partir de widgetMapper pov je serais une fonction addUser ($ widget, $ user). Les deux peuvent être faits, les deux sont corrects, les deux peuvent être utiles à avoir. Je resterais avec les saveUserWidgets (ou peut-être les rendre même atomar, comme addWidget ($ User, $ widget) et removeWidget (...)) en fonction de ce que vous faites. Chaque fonction est autorisée ici aussi longtemps que vous savez ce qu'ils font;) Il n'y a pas de "fonctions interdites" ou de "fonctions incontournables" pour le mappeur. – Fge