Где должна располагаться бизнес-логика при использовании Doctrine 2 и Zend Framework

Question

У меня вопрос, связанный с Doctrine 2 и Zend Framework.

Если вы используете Zend Framework без Doctrine по умолчанию, вы помещаете бизнес-логику в модели.Но поскольку в Doctrine 2 есть сущности, куда следует помещать бизнес-логику?

Сначала я создал модели, в которых менеджер сущностей обращался к сущностям.Но когда я хотел написать модульные тесты для моих моделей без вызовов базы данных.Мне нужно было перенести менеджер сущностей на контроллеры.Но я получаю бизнес-логику в своих контроллерах, что нехорошо.

Приведенный ниже код показывает часть действия контроллера:

        $customerAddress = $this->_model->save($values, $id);

        $this->_em->persist($customerAddress);

        // Update default billing address
        $defaultBilling = $this->_model->saveDefaultBilling($values, $customerAddress);
        if ($defaultBilling != FALSE) {
            $this->_em->persist($defaultBilling);
        }

        // Update default shipping address
        $defaultShipping = $this->_model->saveDefaultShipping($values, $customerAddress);
        if ($defaultShipping != FALSE) {
            $this->_em->persist($defaultShipping);
        }

        $this->_em->flush();

Может кто-нибудь сказать, что лучше для этоговопрос?Thx

Answer 1

Я не уверен, что существует согласованная передовая практика, но я вижу много разговоров о сервисных уровнях при обсуждении Doctrine или Zend Framework.

Когда я запустил свое приложение с Doctrine, я попытался встроить как можно больше функциональных возможностей в свои объекты Entity, но быстро понял, что это почти невозможно без внедрения Entity Manager, что полностью разрушает идею простого непостоянства осознанные объекты, которые делают Doctrine 2 таким милым.

Если вы выходец из мира Active Record, вам легко представить вашу «модель» как отдельный объект, который соответствует таблице базы данных и контроллеры должны взаимодействовать с этими объектами. Это обычно хорошо для очень простых приложений CRUD. Но из-за подхода Доктрины делать это таким странным и разочаровывающим образом.

Вместо этого подумайте о различных слоях в вашем приложении. Doctrine - это слой, который находится поверх базы данных, ваши сущности располагаются поверх Doctrine, а ваш уровень обслуживания должен располагаться поверх ваших сущностей. Весь этот пакет - ваш M в MVC, и он включает в себя как постоянство данных, так и бизнес-логику.

Я бы посоветовал вам ознакомиться с этой презентацией по теме.

UPDATE

Первоначально я пропустил ту часть, где вы упомянули, что у вас были отдельные объекты модели, делающие вызовы к сущностям. Я думаю, что это будет приемлемый шаблон для использования. Если вы хотите писать тесты без выполнения вызовов базы данных, вы, вероятно, захотите использовать макет Entity Manager - это зависимость, независимо от того, в какой слой вы его поместите.

Answer 2

Вот проект скелета github, который я использовал, он выполнял инициализацию доктрины 2 с Zend Franework 1.11.2 в начальной загрузке, красиво и чисто, используя модель для сущностей и репозиторий моделей для бизнес-логики. Модульные тесты и скрипт сборки Ant для вас, разработчиков TDD.

https://github.com/eddiejaoude/Zend-Framework--Doctrine-ORM--PHPUnit--Ant--Jenkins-CI--TDD-