使用应用程序范围的 TraceSource 的最佳实践
因此,我有一个应用程序,我将在其中使用跟踪来记录应用程序活动/错误等。大多数信息将进入日志文件,而一些错误也会进入事件查看器。该应用程序将有很多类。
在这种情况下使用 TraceSource 的最佳方法是什么?我应该创建一个单例包装 TestSource 类还是有更好的方法?
So I have an application where I will be using tracing for logging application activity/errors etc. Most information will go in a log file whereas some errors will go in event viewer too. This application will have lots of classes.
What is the best way of using TraceSource in this case? Should I create a singleton wrapping TestSource class or is there any better way of doing it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我在某种程度上同意@Valdis - log4net 和 NLog 是非常强大的日志框架的两个示例,它们提供了很大的灵活性和相对易于使用的配置(NLog 可能比 log4net 更容易配置)。但是,我认为没有必要完全避免 TraceSource。 TraceSource 是内置的,因此您可以避免额外的依赖。
如果您使用 TraceSource,我不认为单个应用程序范围的静态 TraceSource 对象是可行的方法。我建议使用更多 TraceSource,甚至可能每个类一个(这可能有点过分,但在使用 log4net 和 NLog 时是一种常见模式)。
我已在您的另一个问题的答案中提供了更多详细信息,该问题涉及何时在应用程序中使用多个 TraceSource。
I agree to some extent with @Valdis - log4net and NLog are two examples of very powerful logging frameworks that offer a great deal of flexibility and relatively easy to use configuration (NLog is probably easier to configure than log4net). However, I don't think that is necessary to completely avoid TraceSource. TraceSource is built in so you avoid an extra dependency.
If you are using TraceSource I don't think that a single application wide static TraceSource object is the way to go. I would recommend using more TraceSources, possibly even one per class (that might be overkill, but is a common pattern when using log4net and NLog).
I have put more details in an answer to your other question about when to use more than one TraceSource in an application.
您是否严格使用内置的 .net 事件和日志记录基础设施?我鼓励使用一些第三方(例如从企业库登录)。这些更灵活,更可配置,并且您不会遇到这样的麻烦 - 您只需编写:
are you strict to use built-in .net eventing and logging infrastructure? I would encourage to use some of the 3rd parties (like logging from Enterprise Library). those are more flexible, more configurable and you do not have a headackes like these - you just write: