Oop 深度与平面对象模型

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

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

• 服务器
• 数据库
• 纵队
• 观点

您会推荐哪种选择：

每个服务器对象都包含一个 数据库对象。每个数据库 对象包含列列表和 视图列表等

每个对象都是一个“哑”对象，只包含自己的属性，并且 您提供了一组服务来 检索层次结构，例如 GetServerDatabases（服务器）， GetDatabaseColumns（数据库）

---

我喜欢第一种方法。尽管有时您可能会过度设计并创建太细粒度的类，但总的来说，我认为每个对象都具有智能的树状结构比一组带有一组辅助方法的“哑”对象要好得多，而且面向对象。

我相信第二种方法，匹配FlyWeight模式：对象不会直接聚合其子对象，它们只知道如何到达它们。在使用数据库时，您不需要始终显示所有层次结构，因此在本文中，我更喜欢哑巴方法

---

不过，FlyWeight可以通过一些缓存来丰富，以避免对同一数据进行多次检索。

如果您遵循OO设计原则，则两者都适用。第二个选项称为协调对象，有助于防止API/核心的状态（无论您想要哪个名称）被篡改和破坏

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

我自己的偏好是限制4个对象上的任何setter，并通过coordination/façade对象（）强制设置。让服务器将其数据库作为属性提供，等等

正如前面指出的，Server.Databases属性可能很重。在这种情况下，可以通过协调对象（立面）进行访问

因此：

---

依此类推

如果您使用Hibernate或类似Hibernate的映射，那么我肯定会使用深层对象层次结构。

您也可以同时使用这两种结构。命令的深度模型和查询的平面模型。这称为命令查询分离（CQS），在应用之前，我建议您寻求更多关于它的知识。

您的数据库模式应该是适合您需要的。如果您需要引用完整性，并且希望依赖一些数据库级联特性，并且没有太大的性能瓶颈，那么您的模式应该反映这一点。在使用RDBMS时，如果有充分的理由，您希望将表展平，否则，最终会出现大量重复或空字段，这会消耗资源并使查询复杂化，因为它们考虑了所有特殊情况—使用RDBMS设计的基于集合的操作要容易得多。如果您遵循将表与域中的每个“实体”相匹配的方法，您应该可以

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

GetServers()
GetDatabases(Server)
GetColumns(Database)