Injection Dependence and Unit of Work

Question

I have a dilemma. I used DI (read: factory) to provide the basic components for a homegrown ORM. The on-demand container provides database connections, DAO, Mappers, and their resulting domain objects.

Here is a general outline of the Mappers and Domain Object classes.

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 } } 

ORM also contains a class (Monitor) based on the Unit of Work ie

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

The ORM class itself simply coordinates the resources retrieved from the DI container. So, to create a new User object:

 $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" 

My question is that. At that moment, when the user sets the values ​​in the class of domain objects, I need to mark the class as "dirty" in the "Monitor" class. I have one of three options, as I see it

1: pass an instance of the Monitor class to a domain object. I noticed that this is marked as recursive in FirePHP - i.e. $ This-> Monitor-> markModified ($ this)

2: instantly starting the monitor directly in the domain object - does it break the DI? 3: Make monitoring methods static and call them from within a domain object - does this also interrupt DI?

What will be your recommended course of action (besides using the existing ORM, I do this for fun ...)

Answer 1

Ok, I see. What about this:

  $user = new User; $monitoredUser = new Monitor( $user ); //at update in class Monitor: Monitor::markDirty( $this ); 

Now you use the monitor as a decorator; it adds a wrapper around a user object or any other object that processes incoming requests. If the object is updated, it will be polluted by the monitor, however, since the monitor uses the static method for this, it remains within the current class, thereby avoiding recursion.

Answer 2

Thought I never did this, your Monitor class seems to fit the "Observer" design pattern. Thus, you do not need to ask the Monitor class to mark the class as dirty, but it must do it alone.

As I said, I never did this in PHP, but I'm sure you can look at Google how to implement this design pattern in PHP.

Answer 3

The big question; what happens inside markModified () ..? I copied the code and tried it, but I did not receive the error message. So, I think one piece of the puzzle is missing?