好的 - 我需要实现统计/数据点/数据源系统。
我基本上希望定期将数据传递给'root',并让它处理并更新相关属性以便在整个应用程序中进行访问 - 作为图形,标签,状态检查等的数据源。
我想知道过去曾经处理过类似事情的用户是否有一些现实世界的例子。我用谷歌搜索出了这个问题,我不断得到一些关于我应该做什么的结果,我讨厌编程和'让这些部分落到实处'。我需要一个方向。
为清晰起见编辑: 数据来源将是:
子系统的类型(有限列表,仅用于说明目的):
正如我所说,如果需要(可能会出现这种情况),很多这些来源可用于协作以更新数据段。可以在多个系统中使用一条信息,但有时候获取对于一个点非常具体。
我希望能让它更清晰......也许吧。如果可能的话,我想在一个区域处理所有数据处理。随着流量的增加,它会更容易使用。
我写了一些关于它的想法,因为头脑风暴的想法。
观察者模式
这种模式似乎很好,但它确实有一些缺点,因为所有潜水艇都会被通知而不是选择性潜水艇。这将迫使我检查数据然后处理,或为每种类型的数据创建多个可观察对象,并让它级联到子。我非常喜欢这是多么可扩展,也允许我在需要时分到多种类型的数据源。另一方面,获得任何结果似乎也是很多工作。按原样支付它。
策略
这种模式似乎也很相似,但方式不同。分别存储原始数据的处理,并且只有一个包含所有统计信息的父类(可以这么说)。我喜欢这个,因为所有信息都集中存储,“节点”处理它并返回它。允许轻松访问和存储,但是属性的数量(除非我将其拆分,可能)将是巨大的。
自定义活动。
现在 - 我猜这个 COULD 被视为第一个的重塑。但我确实喜欢它提供的控制。
观察者与策略的结合。
这可能很奇怪,但是听我说。因此,您的可观察对象将数据传递给它,它会向下级联到适当的子级,这些子级将根据不同的原因处理该信息,然后使用每个子级的策略并相应地处理信息并将其传递回子级。存储/访问。
这方面的一个例子是定期从某种来源撤回数据;此信息可用于更新系统的多个区域(观察者),但每个区域需要以不同的方式处理(策略)。
这个逻辑是否合理,或者我应该以不同的方式看待它。我确实需要这个可扩展和可扩展,因为系统可能会处理“大”卷。
思考?试图具体但仍然是主题。
答案 0 :(得分:2)
我结束了观察员和战略的结合,并引发了一些海关事件。有趣的是如何运作。它实际上运行得非常好 - 轻量级,可扩展和可扩展的测试使用'大'(5-7gig)输入。每次都有所需的结果。虽然没有发生援助,但我认为我会分享观察员/战略组合实际运作良好的事实。