Внедрение зависимостей и единица работы

Question

У меня дилемма. Я использовал DI (читай: фабрика) для предоставления основных компонентов для доморощенного ORM. Контейнер предоставляет соединения с базой данных, DAO, Mappers и их результирующие доменные объекты по запросу.

Вот основная схема классов Mappers и Domain Object

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 также содержит класс (Monitor) на основе шаблона «Единица работы», т.е.

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

Сам класс ORM просто координирует ресурсы, извлеченные из контейнера DI. Итак, чтобы создать новый объект User:

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

Мой вопрос такой. В тот момент, когда пользователь устанавливает значения в классе Object Domain, мне нужно пометить класс как «грязный» в классе Monitor. У меня есть один из трех вариантов, который я вижу

1: передать экземпляр класса Monitor объекту Domain. Я заметил, что это помечено как рекурсивное в FirePHP - т.е. $ This-> Монитор-> markModified ($ это)

2: создание экземпляра Monitor непосредственно в доменном объекте - это нарушает DI? 3: Сделать методы Monitor статичными и вызывать их изнутри объекта Domain - это тоже нарушает DI, не так ли?

Каким будет ваш рекомендуемый курс действий (кроме использования существующего ORM, я делаю это для развлечения ...)

Answer 1

Хорошо, я вижу. Как насчет этого:

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

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

Теперь вы используете монитор в качестве декоратора; он добавляет оболочку вокруг пользовательского объекта или любого другого объекта, который обрабатывает входящие запросы. Если объект обновляется, он будет помечен монитором как грязный, однако, поскольку монитор использует статический метод, он остается в пределах текущей области класса, что позволяет избежать рекурсии.

Answer 2

Большой вопрос;что происходит внутри markModified () ..?Я скопировал код и попробовал его, но не получил сообщение об ошибке, о которой вы сообщили.Итак, я думаю, что один кусок головоломки отсутствует?

Answer 3

Хотя я никогда этого не делал, ваш класс Monitor, кажется, соответствует шаблону проектирования "Observer". Таким образом, вам не нужно просить класс Monitor пометить класс как грязный, но он должен сделать это один.

Как я уже сказал, я никогда не делал этого на PHP, но я уверен, что вы можете найти в Google способ реализации этого шаблона проектирования в PHP.