Question

我有一个与Doctrine 2和Zend Framework相关的问题。

如果您默认使用不带Doctrine的Zend Framework，则将业务逻辑放在模型中。但是，由于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时，我看到很多关于Service Layers的讨论。

当我使用Doctrine启动我的应用程序时，我尝试尽可能多地在我的Entity对象中构建功能，但很快就意识到如果不注入实体管理器几乎是不可能的，这完全违背了普通，非持久性的想法 - 知道对象使Doctrine 2变得如此美好。

如果您来自Active Record世界，很容易将您的“模型”视为与数据库表对应的单个对象，并且控制器必须与这些对象进行通信。对于非常简单的CRUD应用程序，这通常是可以的。但是由于Doctrine的方法，这样做是奇怪和令人沮丧的。

相反，请考虑应用程序中的不同层。 Doctrine是一个位于数据库顶部的层，您的实体位于Doctrine之上，您的服务层应位于您的实体之上。整个包是MVC中的M，它包含数据持久性和业务逻辑。

我建议您查看有关该主题的presentation。

<强>更新

我最初错过了你提到你有单独的模型对象调用实体的部分。我认为这是一种可以接受的模式。如果你想在不进行数据库调用的情况下编写测试，你可能会想要使用实体管理器的模拟 - 无论你把它放在哪一层，它都是一个依赖。

Answer 2

这是我使用的github骨架项目，它在引导程序中使用Zend Franework 1.11.2进行了原则2初始化，漂亮而干净，使用了实体和模型的模型。业务逻辑的模型库。单元测试＆amp;蚂蚁构建脚本也适合TDD开发人员。

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

在使用Doctrine 2和Zend Framework时，应该在哪里放置业务逻辑

2 个答案: