在使用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();

有人可以说这个问题的最佳做法是什么？谢谢

Answer 1

我不确定是否有一个商定的最佳实践,但在讨论Doctrine或Zend Framework时,我看到很多关于Service Layers的讨论.

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

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

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

我建议你查看这个主题的演示文稿.

UPDATE

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