如何使用Zend Framework正确创建域? [英] How To Properly Create Domain using Zend Framework?

问题描述

我问了这个问题但现在我希望在数据库访问层和域层之间实现实际的隔离.我还将努力将业务逻辑移入它所属的域并从控制器脚本中移出.

I asked this question a while back but now I'm looking to implement an actual separation between my database access layer and the domain layer. I am also going to be working to move business logic into the domain where it belongs and out of the controller scripts.

我正在使用Zend Framework，它为数据访问层实现了表数据网关和行数据网关模式，但显然无法真正定义如何构建与数据访问层分离的域层.我曾考虑过使用Active Record模式，在该模式中域逻辑与数据访问逻辑共存，但是我有以下情况至少在一次我认为Active Record无法处理的情况下发生:

I'm using Zend Framework which implements the Table Data Gateway and Row Data Gateway patterns for the data access layer, but it apparently fails to really define how to build a domain layer that is separate from the data access layer. I've considered using an Active Record pattern where the domain logic coexists with the data access logic, but I have the following situation that occurs at least once that I don't think Active Record will handle:

我只有一个表"Person"，其中包含person_id和userType字段.

I have a single table "Person" which contains person_id and userType fields.

每个userType(管理员，买方，助理，主管)都有特定的业务逻辑，并且所有类型都继承自Person对象的一些基本功能.

Each userType (admin, buyer, associate, supervisor) has specific business logic associated with it and all types inherit some basic functionality from a Person object.

我不想使用专门属于一种类型的用户的业务逻辑来夸大Row Data Gateway对象，但是我不确定如何构造域层来表示不同类型的用户.例如，我是制作一个包含PersonGateway对象的Person对象，然后编写将调用传递给网关对象的包装函数，还是编写Person对象来扩展PersonGateway对象，然后仅实现所需的特定功能?

I don't want to bloat the Row Data Gateway object with business logic that belongs specifically to just one type of user but I'm not certain how to construct the domain layer to represent the different types of users. For example, do I make a Person object that contains the PersonGateway object and then write wrapper functions that pass calls to the gateway object, or do I write the Person object to extend the PersonGateway object and then only implement the specific functions that I need?

同样，我通常会认为这是(部分)工厂问题，我需要一种工厂方法，该方法将基于userType实例化正确的子类. Zend Framework的Zend_Db类仍然是最好的方法吗?

Likewise, I would typically think that this is (in part) a factory problem where I need a factory method that will instantiate the correct sub-class based on userType. Is that still the best method here with Zend Framework's Zend_Db class?

任何有关在Zend_Db顶部如何正确创建域模型的建议或教程链接都将不胜感激.

Any suggestions or links to tutorials that talk about how to properly create a domain model on top of Zend_Db would be greatly appreciated.

推荐答案

域模型没有扩展任何内容.它们只是用于封装业务逻辑的普通类.它们可能使用数据访问对象，因此类中可能存在行数据网关对象的protected实例. Row对象通常比Table对象更接近地表示域的实例.此外，您始终可以使用Row的getTable()方法获取Table对象.

Domain Models extend nothing. They're just plain classes you use to encapsulate business logic. They may use data access objects, so there may be a protected instance of a row data gateway object inside the class. A Row object usually represents an instance of the domain more closely than a Table object. Besides, you can always get the Table object with the Row's getTable() method.

通常，DM类具有一个接口，该接口具有与您可以对该类执行的更高级别操作相对应的方法.但是您不一定要浮出水面.

Typically DM classes have an interface with methods corresponding to higher-level operations you can do with that class. But you don't necessarily want to surface all data access operations.

class Person {
  // Zend_Db_Table_Row object
  protected $data; 

  public function subscribeToService(Service $service) { ... }

  public function sendMailTo(Person $recipient) { ... }

  public function changePassword($newPassword) { ... }
}

我上次在 spring 上也写过关于这个主题的博客. ，并将其写在ZF邮件列表

I also blogged about this subject last spring, and wrote about it on the ZF mailing list recently.

关于教程和资源，请尝试 http://domaindrivendesign.org/

As far as tutorials and resources, try http://domaindrivendesign.org/

这篇关于如何使用Zend Framework正确创建域?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！