适当的事件日志解析器设计模式？ [英] Appropriate design pattern for an event log parser?

问题描述

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

Working on a project that parses a log of events, and then updates a model based on properties of those events. I've been pretty lazy about "getting it done" and more concerned about upfront optimization, lean code, and proper design patterns. Mostly a self-teaching experiment. I am interested in what patterns more experienced designers think are relevant, or what type of pseudocoded object architecture would be the best, easiest to maintain and so on.

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

There can be 500,000 events in a single log, and there are about 60 types of events, all of which share about 7 base properties and then have 0 to 15 additional properties depending on the event type. The type of event is the 2nd property in the log file in each line.

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

So for I've tried a really ugly imperative parser that walks through the log line by line and then processes events line by line. Then I tried a lexical specification that uses a "nextEvent" pattern, which is called in a loop and processed. Then I tried a plain old "parse" method that never returns and just fires events to registered listener callbacks. I've tried both a single callback regardless of event type, and a callback method specific to each event type.

我尝试了一个带有a的基本事件类所有可能属性的联合。我试图避免新事件调用（因为可能存在大量事件并且事件对象通常是短暂的）并且具有带有原始属性参数的每种类型的回调方法。我已经尝试为60个事件类型中的每一个设置一个子类，其中一个抽象的事件父类具有7个公共基本属性。

I've tried a base "event" class with a union of all possible properties. I've tried to avoid the "new Event" call (since there can be a huge number of events and the event objects are generally short lived) and having the callback methods per type with primitive property arguments. I've tried having a subclass for each of the 60 event types with an abstract Event parent with the 7 common base properties.

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

I recently tried taking that further and using a Command pattern to put event handling code per event type. I am not sure I like this and its really similar to the callbacks per type approach, just code is inside an execute function in the type subclasses versus the callback methods per type.

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

The problem is that alot of the model updating logic is shared, and alot of it is specific to the subclass, and I am just starting to get confused about the whole thing. I am hoping someone can at least point me in a direction to consider!

推荐答案

嗯......一件事而不是一件事单个事件类与所有属性的联合，或61个事件类（1个基数，60个子），在具有这么多变化的场景中，我很想拥有一个使用属性包的单个事件类（字典，哈希表，w / e漂浮你的船）来存储活动信息。事件的类型只是一个属性值，可以放入包中。我倾向于这种方式的主要原因仅仅是因为我不愿意维护60个派生类的任何东西。

Well... for one thing rather than a single event class with a union of all the properties, or 61 event classes (1 base, 60 subs), in a scenario with that much variation, I'd be tempted to have a single event class that uses a property bag (dictionary, hashtable, w/e floats your boat) to store event information. The type of the event is just one more property value that gets put into the bag. The main reason I'd lean that way is just because I'd be loathe to maintain 60 derived classes of anything.

最大的问题是......你是什么？在处理事件时必须执行事件。你把它们格式化成一个报告，把它们组织成一个数据库表，如果发生某些事件就叫醒别人......什么？

The big question is... what do you have to do with the events as you process them. Do you format them into a report, organize them into a database table, wake people up if certain events occur... what?

这是否意味着 - 事实解析器，还是实时事件处理程序？我的意思是，您是在事件进入时监控日志，还是在第二天解析日志文件？

Is this meant to be an after-the-fact parser, or a real-time event handler? I mean, are you monitoring the log as events come in, or just parsing log files the next day?

这篇关于适当的事件日志解析器设计模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！