Вопрос по model-view-controller, orm, php, doctrine-orm – Расширение Doctrine Entity для добавления бизнес-логики

8

Я пытаюсь применить хороший дизайн и расширить сущность Доктрины. Мой расширенный класс, в основном модель, будет иметь дополнительную бизнес-логику + доступ к базовым данным сущности.

Я использую Doctrine 2.2.1 & amp; Zend Framework 1.11.4 & amp; php 5.3.8

Когда я использую DQL, доктрина успешно возвращает сущность Model. Когда я использую встроенную в Doctrine функцию find (), она ничего не возвращает :(.

ПОМОГИТЕ...

This is how it rolls:

Bootstrap.php:

    $classLoader = new \Doctrine\Common\ClassLoader('Entities', APPLICATION_PATH.'/doctrine');
    $classLoader->register();
    $classLoader = new \Doctrine\Common\ClassLoader('Models', APPLICATION_PATH);
    $classLoader->register();

Model in APPLICATION_PATH\models\User.php:

namespace Models;
use Doctrine\ORM\Query;

/**
 * Models\User
 *
 * @Table(name="user")
 * @Entity
 */
class User extends \Entities\User {

public function __wakeup() {
    $this->tools = new Application_App_Tools();
}

Entity retrieval functions:

DOESN'T WORK:

$userEntity = $registry->entityManager->find('Models\User', $userEntity);

WORKS:

$qry = $qb
        ->select('u')
        ->from('Models\User','u'); 
Я только сейчас заметил, действительно ли у вас есть вызов скрипта для Model \ User или это просто опечатка здесь? Ivan Hušnjak

Ваш Ответ

3   ответа
0

То, что я пытался сделать, было плохой практикой. Я связал свою сущность БД и инструменты от Zend, как упомянул @Ivan Hu & # x161; njak.

Что должно быть сделано, это разъединение.

Бизнес-логика должна находиться в службах \ контроллере, и они должны адресовать сущность и ее методы. Вы можете \ должны добавить вспомогательные функции к сущности доктрины, котораяonly относится к свойствам объекта.

Что касается моей основной цели (иметь класс сущностей, который Doctrine CLI может переписать и обновить): доктрина только ищет изменения в собственных полях \ методах, обновляет их соответствующим образом и удаляет все другие функции (помощники). так что нет проблем, когда доктрина обновляет сущность php!

постскриптум перейти к symfony2.

& # xAB; Бизнес-логика должна быть в services \ controller & # xBB; & # X2013; очень плохая идея Бизнес-логика должна быть в ваших моделях как можно больше. Не могу понять, по какой причине вы разделили модели и сущности. Почему бы просто не поместить свою бизнес-логику в сущности доктрины, которые (честно говоря) являются именно вашими моделями.
Хорошо, я вижу несколько предложений - пытаюсь сделать что-то подобное. В моем случае хорошим примером будет то, что у меня есть сущность User, сопоставленная один-ко-многим с сущностью Address. Некоторые поля одинаковы для обоих, но на самом деле они не являются расширениями друг друга - то есть они имеют «имя». поля, номер телефона, адрес электронной почты. Я хотел бы, чтобы функция создала новый адрес для данного пользователя, который будет предварительно заполнять эти похожие поля (возможно, будет изменен позже). Я вижу примеры добавления таких функций к сущности, моделям, картографам. Что такое лучшие практики?
@zeliboba Я согласен, что помещать бизнес-логику в контроллеры - это плохая идея, она просто грязная. Что касается разделения сущностей и бизнес-логики, каждый ресурс, с которым я сталкивался, утверждает, что вам НЕ следует добавлять бизнес-логику к сущностям. Очевидно, это плохо для ваших организаций, особенно когда они растут, но я не понимаю, почему это так, ТБХ.
4

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

Use models for business logic. Create custom Doctrine 2 repositories for your all your database queries (DQL or otherwise) [1]. Leave your entities alone.

На практике это означает, что модели - это простые классы PHP (или, может быть, расширение инфраструктуры в зависимости от того, что вы используете), но ваши модели не имеют отношения к вашей базе данных. Однако ваши модели создают ваши собственные репозитории Doctrine 2. Например.UserRepository может содержать метод с именемgetUserById, В ваших репозиториях вы выполняете свои реальные запросы и возвращаете экземпляры сущностей для моделей, с которыми можно работать.

[1] http://docs.doctrine-project.org/en/latest/reference/working-with-objects.html#custom-repositories

1

Как я понимаю учение,entityManager отвечает только за постоянные сущности, и расширениеEntities\User сущность сModel\User создаст другую сущность (хранится в той же таблице, как указано в docblock), но не управляетсяentityManager или столкнулся с ним, потому что вы, вероятно, не упомянули@InheritanceType("SINGLE_TABLE") вEntities\User docblocks:

Прочитайте эту документацию для получения дополнительной информацииhttp://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html

Я удалил & amp; отредактировал первый комментарий, но я не вижу вашего ответа. извиняюсь. В любом случае, мне не нужен этот функционал. Я хочу добавить конкретную функцию к конкретной сущности. в отношении моего примера, что класс User будет иметь функции, которые будут выполняться над пользователем. такие как sendPushNotifications и т. д. ohadwkn
MappedSuperclassBase должен быть основой любой другой сущности, определять их общие свойства и методы, дочерние классы являются конкретными сущностями ... Пример: GeneralUser - это суперкласс с общими полями, Editor и Supervisor расширяют его своими конкретными полями, такими как Editor.assignedTopics или Supervisor .topicsToCheckout ... надеюсь, это поможет
да, это решение, которое я выбрал. Я просто хотел спасти$model = new Models\User($entity); и сделать код намного более элегантным .. ценим помощь! ohadwkn
Таким образом, вы хотите иметь всю логику хранилища / логики в вашем Entities \ User и всю бизнес-логику в Models \ User? В этом случае нет причин держать вашу модель в управлении Doctrine entityManager, поскольку она, очевидно, не является сущностью. Пусть ваша модель скорее использует сущность, а не расширяет ее следующим образом: $ model = new Models \ User ($ entity); $ Model- & GT; doSomeBusinessLogic ();
Спасибо за комментарий. Относительно моей конкретной потребности: MappedSuperclassBase должен содержать бизнес-логику? По сути, основная цель - создать класс сущностей, который Doctrine CLI может переписать и amp; обновление в соответствии с определениями YAML. И я хочу иметь возможность добавлять бизнес-функции с возможностями Zend в расширяющийся класс, не беспокоясь о синхронизации и слиянии. Если можно, как бы вы решили эту проблему? ohadwkn

Похожие вопросы