1. 首页
  2. 问答
  3. 当使用Doctrine 2和Zend Framework时，应该在哪里放置业务逻辑

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

2010-09-29 104 views
9

我有一个与Doctrine 2和Zend Framework相关的问题。当使用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

来源

2010-09-29 tom

+0

我认为这是最好的，所有的学说代码移出控制器，进入领域类，请查看我的博客文章：http://www.cobbweb.me/2010/11/integrate-doctrine- 2-zend-framework-application/ – Cobby 2010-11-23 00:15:00

回答

13

我不确定是否有一致同意的最佳实践，但在讨论Doctrine或Zend Framework时，我看到很多关于服务层的讨论。

当我开始我的应用程序学说，我试图建立尽可能多的功能集成到我的实体对象，我可以，但很快就意识到没有注入实体管理器，它完全打破了平原，非持久性的想法，几乎是不可能的使Doctrine 2非常好的意识对象。

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

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

我建议你看看这个话题presentation。

UPDATE

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

来源

2010-09-29 13:05:31

+0

我认为这里的诀窍是设计你的模型，使其与持久性无关，也就是说，它可以通过全新调用new并从文字设置属性完全实例化。每个协作中的每个需要的对象都应该可以通过遍历对象图来访问（通过由原则的关系映射创建的对象引用），因此实体中不需要实体管理器。 – 2013-02-19 23:32:55

相关问题

 相关问题