我正在设计（和编码）一个报告引擎，为报告生成聚合的数据 - 这是关于表示层的不。
示例： 我有一个充满人事记录的数据库。数据库中的每个人都有大约15个属性。
我的报告需要
我主要担心的是，我的很多的业务规则在形式上非常相似，但有各种不同的小细节。我想确保用一种可维护且易于理解的方法来编写它，因为根据我的经验，这通常会成为一个非常长的文件，其中包含许多嵌套的if-else，这些文件很难维护。
我有大量的报告，我想尽可能多地预先计算报告。我知道实际上可能存在无穷无尽的报告标准，因此我还需要动态生成报告。我想在一个地方保留预先计算和临时报告的逻辑。
此处的报告数据是产品，因此需要快速发布，并转发给最终用户。
当前设计包括存储在CouchDB中的数据以及在nodeJS上完成的处理。如果有更容易/更快速的东西，可以更改这些。我有几十万条记录，我不会说这是大数据＆＃39; （但当然 - 这可能会增长）。
谢谢！
答案 0 :(得分：0)
由于您将拥有多个需要相互交互的业务规则，因此首先想到的设计模式是Decorator Pattern。此模式的目的是在给定对象通过时向其添加信息。因此，您可以拥有一个给出人员列表的行为，识别特定年龄段的行为。然后它将此子列表传递给另一个行为，例如，按性别等排序等。
但是，由于业务规则很容易发生变化，因此您需要使代码具有灵活性。要做到这一点，在我看来你应该使用Strategy Pattern因为它允许你指定各种算法然后你可以传递给你的报告算法（你的应用程序的主要核心，负责将所有内容呈现为用户希望它能够在不关心您使用何种信息的情况下进行操作。这样可以更轻松地更改和/或扩展报告工具的行为。
最后，如果您正在使用我假设的数据库，您可以使用Singleton Pattern来管理数据库连接和交互。话虽这么说，你很可能会发现这种语言可以用你选择的语言。