哪些设计模式可能对创建逻辑报表引擎有用？

Question

我正在设计（和编码）一个报告引擎，它为报告生成聚合的数据 - 这不是关于表示层的。

示例： 我有一个充满人员记录的数据库。数据库中的每个人都有大约 15 个属性。

我的报告需要

1. 根据大约 15 条业务规则选择特定的一组人员。这些比单纯的 WHERE 子句更类似于逻辑流动算法，例如： 以所有 18-25 岁的个体经营者为例。如果少于 100 人，还包括 25-28 岁的年龄组...如果仍然少于 100 人，还包括学生...这样继续...
2. 在获得我正在处理的特定组之后，我需要创建多个数据集，这些数据集按不同的分组并包含不同的指标。例如，平均身高 - 按体重分组，平均收入 - 按年龄分组......这些也有复杂的业务规则，比如 - 如果一个年龄段的人少于 5 人，则将其与相邻的有里面的人少，但不管怎样总是独立展示20-30岁年龄段的....

我主要担心的是我有很多的业务规则，它们在形式上非常相似，但有各种不同的小细节。我想确保我以一种可维护且易于理解的方式编写它，因为根据我的经验，这通常会成为一个非常长的文件，其中包含许多难以维护的嵌套 if-else。

我有大量的报告，我想预先计算尽可能多的报告。我确实知道实际上可能有无穷无尽的报告标准，所以我还需要即时生成报告。我想将预计算和临时报告的逻辑保留在一个地方。

这里的报告数据是产品，所以这些数据需要非常快地分发给最终用户。

当前的设计包括存储在 CouchDB 中的数据和在 nodeJS 上完成的处理。如果有一些东西可以更容易/更快地使用，这些可以更改。我有几十万条记录，我不会说这是“大数据”（但当然 - 这可能会增长）。

谢谢！！

Answer 1

由于您将拥有多个需要相互交互的业务规则，因此想到的第一个设计模式是Decorator Pattern。此模式的目的是在给定对象通过时为其添加信息。所以你可以有一个行为，它给出了一个人列表，识别出特定年龄段的人。然后它将这个子列表传递给另一个适用的行为，例如，按性别排序等。

但是，由于业务规则容易更改，因此您需要使代码灵活。为此，我认为您应该使用Strategy Pattern，因为它允许您指定各种算法，然后您可以将这些算法传递给您的报告算法（应用程序的主要核心，它负责按照用户的意愿呈现所有内容它，而不用关心你正在处理什么样的信息。这应该更容易改变和/或扩展你的报告工具的行为。

最后，如果您正在使用数据库，我假设您是，您可以使用Singleton Pattern 来管理您的数据库连接和交互。话虽如此，您很可能会发现此类内容已经可用于您选择的语言。