【问题标题】:C# Custom Logger - Best way to capture sending objectC# 自定义记录器 - 捕获发送对象的最佳方式
【发布时间】:2012-12-04 03:36:34
【问题描述】:

我正在尝试构建(用于学习目的)我自己的事件记录器;我对使用非 .net 框架而不是构建自己的框架不感兴趣,因为我这样做是为了更好地理解 .net。

我们的想法是拥有一个事件系统,我可以将其写入日志文件和/或在程序内部提取。为此,我创建了一个 LogEvent 类,该类将存储在 Queue<LogEvent> 中。

我计划在我的LogEvent 课程中使用以下字段:

private EventLogEntryType _eventType //enum: error, info, warning...
private string _eventMessage
private Exception _exception
private DateTime _eventTime

我不确定捕获导致事件被调用的对象的最佳方法。我想过只是做一个private Object _eventObject;,但我认为这不是线程安全的。

任何关于如何最好地存储调用事件的对象的建议都将不胜感激。我也愿意接受您可能提出的任何其他建议。

谢谢,托尼

【问题讨论】:

  • 您想要存储调用事件的对象的原因是什么?如果您打算在对象上简单地使用 .ToString() 来创建日志消息,则最好存储 .ToString() 值。
  • Keo 关注性能。随着主机应用程序的增长,您将开始每秒收集越来越多的消息。进行类型检查并不是确保事情按写入方式进行的最理想方式。在您的示例中,我仍将存储 string 并在调用事件时使用 myObject.CustomField.ToString() 作为参数。
  • @AnthonyNichols - 我可以告诉你,当应用程序非常小的时候,我们就开始使用上述方法。当我们将记录器移到另一个程序集并最终移到另一个进程(一起在 IIS 之外)时,我们花了很多时间来摆脱 IIS 上下文和传递的此类异常对象等。
  • 另外,如果你传递对象,并且它是一个 ref 类型,即不是不可变的,那么在你循环重用变量的情况下,你可以找到一个几乎不可能的错误,例如。
  • @AnthonyNichols - 我指的是实际对象。对不起,如果我不清楚。

标签: c# object logging system.diagnostics


【解决方案1】:

首先,自己编写并没有错。我们那里有一些很好的框架,但有时你会遇到一些奇怪的要求让你自己动手,反正我去过那里......
我认为你不应该使用短信。在几个项目中进行了这种类型的日志记录之后,我得出的结论是,最好的方法是拥有一组带有某种额外信息字段的事件类型(整数 ID)。 你应该有一个LogEvetTypes 的枚举,看起来像这样:

public enum LogEventTypes
{
    //1xxx WS Errors
    ThisOrThatWebServiceError = 1001,

    //2xxx DB access error


    //etc...
}

根据我的经验,这将使您在尝试使用您记录的信息时更加轻松。您还可以添加 ExtraInformation 字段以提供事件实例的特定信息。

至于导致事件的对象,我会使用typeof(YourClass).ToString(); 之类的东西。如果这是您创建的自定义类,您还可以实现 ToString 覆盖,这将在您的日志记录上下文中命名。

编辑:我添加了一些我在 cmets 中写过的细节,因为我认为它们很重要。通过 ref 将不可变的对象传递给服务方法通常不是一个好主意。您可能会在循环中重新分配相同的变量(例如)并创建一个几乎不可能找到的错误。另外,我建议现在做一些额外的工作,将日志记录基础设施与应用程序的实现细节分离,因为稍后这样做会导致很多痛苦。我是根据我自己非常痛苦的经历这么说的。

【讨论】:

  • 扩展@elad-lachmi 的ToString 覆盖。如果您正在滚动所有自己的类,则可能会使用 .LogInfo() 方法创建一个 iLogInformation 接口。
  • @Jastill - 这是真的,但在我的项目中不是一个选项。如果您从头开始构建所有对象,那么您绝对可以让它们都实现一些日志接口之王。
  • 我喜欢使用 .LogInfo() 的想法——但我可能还想将它用于其他项目或不包含该代码的对象。我的想法是使用 Try/Catch 语句,有没有更好的方法?
  • 可能是支持您无法更改的对象的扩展方法。
  • @EladLachmi; @Jastill - 感谢所有帮助!
猜你喜欢
  • 2010-09-05
  • 2021-05-03
  • 1970-01-01
  • 1970-01-01
  • 2023-03-16
  • 1970-01-01
  • 2013-05-03
  • 2020-12-16
  • 1970-01-01
相关资源
最近更新 更多