这是一个通用的问题，我不知道它是属于Programming还是StackOverflow。
我正在写一个小小的模拟。如果不深入细节，请考虑涉及多种身份。它们对应于Object，因为我使用的是OOP语言。
等等。
如果将模拟世界划分为数据库，则对象将是包含大量引用的表，但在内存中我必须使用不同的策略。因此，例如，一个部落有一个Guys作为属性的数组，世界有一个Bots，部落的数组，地图。 Map有一个Dictionary，其键是一个Position，其值是Lot。盖伊的位置就是他的立场。
我放下这种联系的方式几乎是武断的。例如，我可以在世界上拥有一系列的Guys，或者每个人的 （站在一块土地上的人），或者每个Bot的一群人 < / em>（由机器人控制的人）。
这样做，我也必须传递很多对象。例如，Bot必须有关于Map和对手Guys的信息来决定如何移动其Guys。
如上所述，在数据库中，我有一个Guys表连接到Lots表（指示其位置），到Tribe表（指示它属于哪个Tribe），所以它也很容易查询“All位置[1,5]的人“。 “所有部落族人123”。 “Bot B控制的所有伙伴都站在不属于部落456的地段b34”等等。
我使用API在哪里获取最简单的信息来创建CustomerContextCollection的实例并将其传递给CustomerQueryFactory以获取CustomerInPlaceQuery ...当人们批评OOP并引用冗长的抽象时很快就会闻到荒谬， 那就是我的意思。我想避免这样的事情，不得不继续深度抽象和（反模式）抽象语境。
问题是：管理以多种方式深层链接的实体和实体集合的首选干净方式是什么？
答案 0 :(得分：0)
我会说 no 'true'答案存在于您的核心问题中 - 一种最佳方式来管理以多种方式链接的实体集合。它真的取决于应用程序的类型（模拟） - 这里有一些想法：
执行时间是否重要？
如果是这种情况，那么分析实际上没有办法让你的模拟器以哪种方式迭代（查询）池中的对象：勾勒出基本的模拟循环并检查什么样的事件将需要迭代什么样的模型实体（我假设您正在开发离散事件模拟？）。然后，您应该以优化最频繁/耗时事件的方式组织数据结构（而不是“任意放置连接”）。此外，您可能希望使用特殊数据结构（例如k-d trees）来组织具有您需要经常查询的属性的实体（例如，位置数据）。对于一些典型问题，例如碰撞检测，还有很多方法可以有效地解决它们（所以寻找合适的库/框架，例如multi-agent simulation）。
您想要多么灵活？
如果你真的想让它变得超灵活，真的不想决定模型实体的层次结构，为什么不只使用in-memory database？正如您已经说过的，数据库很容易适用于您的问题（您可以轻松保存模型状态，这也可能很有用）。
干净程度如何？
如果您想完全确定模拟器的其余部分不受您对模型表示的设计选择的影响，将其隐藏在界面后面（例如，{{1 }}），它定义模拟器可以调用的所有类型的查询的方法（这与第二点正交，可能有助于第一点，即确定模拟器展示的访问模式类型）。这使您可以轻松地更改实现，而不会影响模拟器代码的任何其他部分。
答案 1 :(得分：0)
这取决于你对“干净”的定义。在我的例子中，我将clean定义为：我可以以明显，有效的方式实现所需的行为。
构建OOP软件不是数据建模练习。我建议稍微退一步。这些对象中的每一个实际上做是什么？你打算用什么方法实现？
仅仅因为“伙伴们很多”并不意味着这个地段对象需要一群人;如果有很多操作影响其中的所有人，它只需要一个。即使在那时，它也不一定需要一个人的集合 - 它需要一种方法来获得批次中的人。这可能是一个内部存储的集合，但它也可能是一个简单的方法，回调世界，找到符合标准的人。该查找的实现对任何人都应该是透明的。
从你的问题的基础，你似乎从“我如何生成报告”的角度思考这个问题。退一步思考你首先尝试实施的行为。
我觉得非常有价值的另一件事是区分实体和价值观。实体是身份很重要的对象 - 你可能有两个人，都叫“克里斯”，但他们是两个不同的对象，尽管有相同的“关键”，仍然是不同的。另一方面，价值观就像整体。从上面的列表中，Position听起来很像一个值 - Position（0,0）是Position（0,0），无论这些位存储在哪个内存块（标识）中。这种区别对你的方式有点影响比较和存储值与实体。例如，您的Guy对象（实体）会将其Position存储为一个简单的成员变量。
我找到了一个很好的参考，如何思考这些东西是Eric Evan的“领域驱动设计”一书。他专注于业务系统，但讨论对于你如何构建我发现的OO系统非常有价值。