适当的事件日志解析器设计模式？

Question

处理解析事件日志的项目,然后根据这些事件的属性更新模型.我一直懒得"完成它",更关心前期优化,精益代码和适当的设计模式.主要是自学实验.我感兴趣的是更有经验的设计师认为相关的模式,或者哪种类型的伪编码对象架构是最好的,最容易维护的等等.

单个日志中可以有500,000个事件,大约有60种类型的事件,所有这些事件共享大约7个基本属性,然后根据事件类型具有0到15个其他属性.事件类型是每行日志文件中的第二个属性.

因此,我尝试了一个非常丑陋的命令式解析器,逐行遍历日志,然后逐行处理事件.然后我尝试了一个使用"nextEvent"模式的词法规范,该模式在循环中被调用并被处理.然后我尝试了一个简单的旧"解析"方法,该方法永远不会返回,只是将事件触发到已注册的侦听器回调.无论事件类型如何,我都尝试过一次回调,以及特定于每种事件类型的回调方法.

我已经尝试了一个基础"事件"类,其中包含所有可能属性的并集.我试图避免"新事件"调用(因为可能存在大量事件并且事件对象通常是短暂的)并且每种类型的回调方法都具有原始属性参数.我已经尝试为60个事件类型中的每一个创建一个子类,并使用具有7个公共基本属性的抽象事件父类.

我最近尝试进一步使用命令模式为每个事件类型放置事件处理代码.我不确定我是否喜欢这个并且它与每种类型的回调方法非常相似,只是代码在类型子类中的执行函数内,而不是每种类型的回调方法.

问题是很多模型更新逻辑是共享的,而且很多都是特定于子类的,我只是开始对整个事情感到困惑.我希望有人能够至少指出我的方向来考虑!

Answer 1

嗯...一方面，在变化如此之多的场景中，我会倾向于拥有一个单一的事件类（具有所有属性的联合），或者 61 个事件类（1 个基本类，60 个子类）。使用属性包（字典、哈希表、让你的船漂浮）的事件类来存储事件信息。事件的类型只是放入包中的又一个属性值。我倾向于这种方式的主要原因只是因为我不愿意维护任何东西的 60 个派生类。

最大的问题是……当你处理这些事件时，你必须如何处理这些事件。您是否将它们格式化为报告，将它们组织到数据库表中，在发生某些事件时唤醒人们......什么？

这是一个事后解析器，还是一个实时事件处理程序？我的意思是，您是在事件发生时监视日志，还是只是在第二天解析日志文件？