表模块 vs. 领域模型

Question

我前几天询问了有关选择存储用户个人资料的方法，收到了来自David Thomas Garcia的有趣的回答，他建议我使用表格模块设计模式。看起来这可能是我想要采取的方向。我在Google上找到的一切似乎都是比较高层次的讨论，所以如果有人能指引我一些示例或给我更好的了解涉及到的具体细节，那就太棒了。

- Kevin Loney

Answer 1

最好的参考资料是Martin Fowler的《企业应用架构模式》：

以下是关于Table Module章节的摘录：

Table Module按表在数据库中每个类来组织领域逻辑，而一个类的单个实例包含将作用于数据的各种过程。与Domain Model最主要的区别在于，如果你有许多订单，Domain Model将针对每个订单拥有一个订单对象，而Table Module将拥有一个对象来处理所有订单。

Table Module在您所描述的用户配置文件数据的灵活数据库架构中特别有用，基本上是实体-属性-值设计。

通常，如果使用Domain Model，底层表中的每一行都成为一个对象实例。由于您正在将用户配置文件信息存储在多个行中，因此您最终需要创建许多Domain Model对象，而您真正想要的是封装所有用户属性的一个对象。

相反，Table Module可以更轻松地为您编写适用于底层数据库表中的多个行的逻辑。如果您为给定用户创建配置文件，则会指定所有这些属性，Table Module类将具有将其转换为一系列INSERT语句的代码，每个属性一个行。

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

同样地，查询给定用户的个人资料会使用表模块将查询结果集的多行映射到对象成员。

$hashArray = $table->getUserProfile( $userid );

- Bill Karwin

---

谢谢，经过大量的阅读和思考后，我终于恍然大悟。 - Kevin Loney

感谢您对它们之间的区别进行了清晰明了的解释。 - BinaryButterfly

@BillKarwin 数据表实体（在业务层中定义的BL），例如“User”或“UserProfile”，是否应该有任何数据访问方面的问题？例如，如果数据访问使用基于属性的映射来实现数据访问上的对象。 BL数据表实体是否应携带这些属性？这不会将BL与数据访问细节耦合吗？我正在尝试建立表模块实现中BL和DAL之间的关系。 - Umair Ishaq

@跟随，最终你必须要有一些类知道如何以你存储数据的方式访问数据。记住，在面向对象编程中创建“层”（layers）的目的是保留交换不同实现的灵活性。如果你没有这个需求，那么创建更多的抽象和层级就没有太大价值了。 - Bill Karwin

@BillKarwin非常感谢您的评论。明确一下，如果不需要灵活性，您不建议将BL和DAL合并。您建议在BL实体中具有这些属性可能是一个合适的妥协方案，对吗？ - Umair Ishaq

@fallow，不了解项目要求很难做出概括性的描述。但是通常情况下，将BL类使用DAL对象是很典型的 -- 推荐使用HAS-A而不是IS-A。 - Bill Karwin