深对比平面对象模型

Question

您会建议哪一种 - 深层对象层次结构（每个对象都包含对子对象的引用）或平面对象（您提供检索子对象的服务）？

假设您正在创建数据库管理应用程序。您将拥有以下对象：

• 服务器
• 数据库
• 列
• 浏览

您会推荐哪个选项：

1. 每个Server对象都包含一个列表 数据库对象。每个数据库 object包含一列和一列 意见清单等
2. 每个对象都是一个“哑”对象，只保留自己的属性，和 你提供一套服务 检索层次结构，例如 GetServerDatabases（服务器）， GetDatabaseColumns（数据库）。

Answer 1

如果你正在进行OO设计原则，那么两者都是正确的。第二个选项称为协调对象，有助于防止API / Core的状态（无论您想要的名称）被篡改和破坏。

第一个选项是内部保存方式，如果您想允许，可以选择允许访问数据库的服务器属性。

我自己的偏好是限制4个对象上的任何setter，并通过coordinating /façade对象（façade pattern）强制执行此操作。让服务器将其数据库作为属性提供，依此类推。

正如所指出的，Server.Databases属性可能很重。在这种情况下，可以通过协调对象（façade）来访问它。

所以：

GetServers()
GetDatabases(Server)
GetColumns(Database)

等等

Answer 2

我认为，第二种方法与FlyWeight模式相匹配：对象不会直接聚合他们的孩子，他们只知道如何去找他们。使用数据库时，您不会需要所有层次结构一直存在，所以在这种情况下，我更喜欢这种愚蠢的方法。

然而，FlyWeight可以通过一些缓存来丰富，以避免多次检索相同的数据。

Answer 3

如果您使用像Hibernate这样的OR-Mapping，那么我肯定会使用深层对象层次结构。

Answer 4

你也可以做到这两点。命令的深度模型和查询的平面模型。这称为命令查询分离（CQS），在申请之前我建议寻求更多的知识。

Answer 5

我更喜欢第一种方法。虽然有时你可能过度工程并创建过于细化的类，但总的来说，我认为每个具有智能的对象的树状结构比使用一组辅助方法的“哑”对象集合更好，面向对象。

Answer 6

您的数据库架构应该是适合您需求的任何内容。如果您需要参照完整性，并且希望依赖某些数据库级联功能，并且没有大的性能瓶颈，那么您的架构应该反映出来。当您使用RDBMS时，您希望在有充分理由的情况下展平表格，否则，最终会出现大量重复或空字段，这会消耗资源并使查询复杂化，因为它们会解决所有特殊情况 - 使用RDBMS设计的基于集合的操作要容易得多。如果您按照将表格与域中的每个“实体”进行匹配的方法，那么您应该没问题。

对于更复杂的实体模型，CQS上的+1。在这种情况下，您可以为命令维护深层模型，并为查询维护单独的扁平版本。如果您不想遵循CQS，您可以将深层模型展平为内存中的DTO。否则，您可以在数据库中创建一组单独的表或视图，以便查询。第二个选项似乎更符合CQS，您可能会更容易地遇到一些您可能遇到的更复杂的查询。