Как я могу "очистить" сущность Doctrine2? - PullRequest
1 голос
/ 10 августа 2011

Я хотел бы создать в своем коде слой, подобный API, который эффективно ограничивает доступ базы данных к коду более высокого уровня. Например, у меня может быть следующая функция:

class MyApi {
    private $my_user_id;
    function getContacts() {
        $contacts = $em->getRepository('Contacts')->findByOwner($this->my_user_id);
        $em->clear();
        return $contacts;
    }
    function getGroups() {
        $groups = $em->getRepository('Groups')->findByOwner($this->my_user_id);
        //hydrate each group's contacts list
        foreach ($groups as $group) {
            $group->getContacts();
        }
        $em->clear();
        return $groups;
    }
}

Я использую $ em-> clear () для отсоединения сущностей от EntityManger перед их возвратом, поэтому мои представления не могут случайно изменить управляемые сущности. Однако я сталкиваюсь с проблемами, когда хочу сравнить сущности, возвращаемые двумя последовательными функциями API. В идеале я хотел бы, чтобы представление / контроллер содержало:

$my_contacts = $myapi->getContacts();
$my_groups = $myapi->getGroups();

foreach($my_groups as $group) {
    foreach ($my_contacts as $contact) {
        if ($group->getContacts()->contains($contact)) {
            echo "{$group->getName()} contains {$contact->getName()}!<br/>";
        } else {
            echo "{$group->getName()} does not contain {$contact->getName()}!<br/>";
        }
    }
}

Однако, поскольку я отсоединил все контакты от EntityManager в конце вызова API getContacts, объекты, возвращаемые $group->getContacts(), отличаются PHP-объектами от объектов, возвращаемых $api->getContacts(), поэтому функция contains() не работает должным образом.

Есть ли у меня какие-либо варианты «отсоединения» моих сущностей, чтобы сделать их доступными только для чтения, не отказываясь от преимуществ, которые предоставляет EntityManager? (Например, все управляемые объекты, представляющие одну и ту же запись базы данных, являются одним и тем же объектом и могут дополнительно увлажнять связанные объекты после их передачи из API и т. Д.)

Ответы [ 2 ]

1 голос
/ 11 августа 2011

Почему вы беспокоитесь о том, что ваши представления будут вносить изменения, которые будут переданы обратно в базу данных? Если ваши представления не знают о EM (и не должны), любые изменения, которые они вносят в объекты, исчезнут в конце запроса.

Единственный другой вариант, который я могу придумать, - это гидрировать ваши результаты в виде массивов, когда они предназначены для подачи в скрипт вида. Но это оставляет много полезной функциональности.

0 голосов
/ 30 марта 2013

Возможно, это немного поздно, но это может быть полезно для всех, кому еще нужен ответ на этот вопрос ...

Я думаю, что здесь отсутствует принцип управляемой доменом конструкции: Командный запросРазделение .
Для каждого объекта вы можете использовать только два вида методов:

doSomething() {
    //this kind of method can change the internal state
}

getSomething() {
    //this kind of method NEVER changes internal state
}

Принимая во внимание надлежащий MVC, представления должны нуждаться только в get-методах и никогда не смогут ничего изменить.
Отказ от вашей сущности не является необходимым и не требует никаких забот, если иметь в виду только CQS и MVC.

...