Table Module vs. Domain Model

我怕爱的太早我们不能终老 提交于 2019-12-02 18:10:45

The best reference is "Patterns of Enterprise Application Architecture" by Martin Fowler:

Here's an excerpt from the section on Table Module:

A Table Module organizes domain logic with one class per table in the database, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model is that, if you have many orders, a Domain Model will have one order object per order while a Table Module will have one object to handle all orders.

Table Module would be particularly useful in the flexible database architecture you have described for your user profile data, basically the Entity-Attribute-Value design.

Typically, if you use Domain Model, each row in the underlying table becomes one object instance. Since you are storing user profile information in multiple rows, then you end up having to create many Domain Model objects, whereas what you really want is one object that encapsulates all the user properties.

Instead, the Table Module makes it easier for you to code logic that applies to multiple rows in the underlying database table. If you create a profile for a given user, you'd specify all those properties, and the Table Module class would have the code to translate that into a series of INSERT statements, one row per property.

$table->setUserProfile( $userid, array('firstname'=>'Kevin', 'lastname'=>'Loney') );

Likewise, querying a given user's profile would use the Table Module to map the multiple rows of the query result set to object members.

$hashArray = $table->getUserProfile( $userid );
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!