Modèle d'injection de dépendances et unité de travail

Question

J'ai un dilemme. J'ai utilisé DI (lire: usine) pour fournir des composants de base pour un ORM homebrew. Le conteneur fournit des connexions de base de données, des DAO, des mappeurs et leurs objets de domaine résultants sur demande.

Voici un aperçu de base des cartographes et des classes d'objets de domaine

class Mapper{ 
    public function __constructor($DAO){ 
     $this->DAO = $DAO; 
     } 

    public function load($id){ 
     if(isset(Monitor::members[$id]){ 
     return Monitor::members[$id]; 

     $values = $this->DAO->selectStmt($id); 
     //field mapping process omitted for brevity 
     $Object = new Object($values); 
     return $Object; 
     } 
    } 

class User(){ 
    public function setName($string){ 
     $this->name = $string; 
     //mark modified by means fair or foul 
    } 
} 

Le ORM contient également une classe (Monitor) basée sur l'unité de modèle de travail à savoir

class Monitor(){ 
    private static array modified; 
    private static array dirty; 
    public function markClean($class); 
    public function markModified($class); 
} 

La classe ORM elle-même coordonne simplement les ressources extraites du conteneur DI. Donc, pour instancier un nouvel objet Utilisateur:

$Container = new DI_Container; 
$ORM = new ORM($Container); 
$User = $ORM->load('user',1); 
//at this point the container instantiates a mapper class 
//and passes a database connection to it via the constructor 
//the mapper then takes the second argument and loads the user with that id 
$User->setName('Rumpelstiltskin');//at this point, User must mark itself as "modified" 

Ma question est. Au moment où un utilisateur définit des valeurs sur une classe d'objets de domaine, je dois marquer la classe comme "sale" dans la classe Monitor. J'ai l'une des trois options que je peux le voir

1: Passer une instance de la classe Monitor à l'objet de domaine. J'ai remarqué que ceci est marqué comme récursif dans FirePHP - c'est-à-dire $ this-> Monitor-> markModified ($ this)

2: Instancier le moniteur directement dans l'objet de domaine - cela brise-t-il DI? 3: Rendre les méthodes Monitor statiques, et les appeler depuis l'intérieur de l'objet de domaine - cela casse aussi DI non?

Quelle serait votre plan d'action recommandé (autre que d'utiliser un ORM existant, je le fais pour le plaisir ...)

Answer 1

D'accord, je vois. Qu'en est-il:

$user = new User; 
$monitoredUser = new Monitor($user); 

//at update in class Monitor: 
Monitor::markDirty($this); 

Maintenant, vous utilisez le moniteur comme décorateur; il ajoute un shell autour de l'objet utilisateur ou de tout autre objet qui gère les requêtes entrantes. Si un objet est mis à jour il sera marqué sale par le moniteur, mais parce que le moniteur utilise une méthode statique pour cela, il reste dans la portée de la classe actuelle évitant ainsi la récursivité.

Answer 2

Je pensais que je ne l'ai fait, votre classe Monitor semble correspondre à un " Observateur "modèle de conception. De cette façon, vous n'avez pas besoin de demander à la classe Monitor de marquer la classe comme sale, mais elle devrait le faire seule.

Comme je l'ai dit je ne l'ai jamais fait en PHP mais je suis assez confiant que vous pouvez regarder sur Google un moyen d'implémenter ce modèle de conception en PHP.

Answer 3

Grande question est; ce qui se passe à l'intérieur de markModified() ..? J'ai copié le code et essayé, mais je n'ai pas l'erreur que vous avez signalé. Donc je suppose qu'il manque un puzzle?