如果一个应用程序将其所有活动数据写入一个日志文件,那么拥有多个 TraceSource 是否有用?我只是对代码中需要多个 TraceSource 的用例感到好奇。
1 回答
有关使用 TraceSources 的良好起点,请参阅其他问题的这些答案:
我想说,任何时候你有不止一个类,你可能(可能)考虑有多个 TraceSource。
拥有多个 TraceSource 的一个优点是它增加了您可以控制日志记录的粒度。例如,如果您在每个类中使用不同的 TraceSource,那么您可以将日志记录控制到类级别。您可以打开一个(或多个)特定课程并关闭所有其他课程。
这是 NLog 和 log4net 用户的常见模式。使用这些日志平台的类的典型初始化将如下所示:
public class A
{
//NLog example
private static Logger logger = LogManager.GetCurrentClassLogger();
public F()
{
logger.Info("Inside F");
}
}
在此示例中,类 A 的记录器以类的完全限定名称命名(NLog 在 GetCurrentClassLogger() 中完成了艰苦的工作)。
要使用 TraceSource 执行类似的操作,您可以执行以下操作:
public class A
{
private static TraceSource ts = new TraceSource(System.Reflection.GetCurrentMethod().DeclaringType.ToString();
public F()
{
ts.Information("Inside F");
}
}
如果您在每个班级都这样做,您可以轻松地按班级控制您的日志记录。
我不太确定这种模式在 TraceSource 中是否与在 log4net 和 NLog 中一样常见。我想你可能更经常看到 TraceSource 的用户按功能区域获取他们的 TraceSource。
因此,您可以将您的应用程序划分为“读取”、“处理”和“写入”功能(或任何对您有意义的功能)。在这种情况下,您可以根据使用它们的功能区域在类中获取适当的 TraceSource:
public class FileReader
{
private static TraceSource ts = new TraceSource("Read");
public F()
{
ts.Information("Hello from FileReader.F");
}
}
public class NetworkReader
{
private static TraceSource ts = new TraceSource("Read");
public F()
{
ts.Information("Hello from NetworkReader.F");
}
}
等等。
现在,您可以为“读取”打开日志记录,并为所有其他功能区域关闭(或为“读取”打开详细日志记录,为所有其他功能区域打开不太详细的日志记录)。
此外,TraceListeners 的选项之一是输出 TraceSource 名称。因此,在您的输出中更容易理解您的日志记录,因为如果您选择这样做,您可以相对容易地找到从特定功能区域(或特定 TraceSource)生成的所有日志记录消息。
如果您有良好的命名空间命名约定,您甚至可以考虑基于命名空间层次结构中的某个节点,甚至基于该类所在的程序集为每个类获取 TraceSource。有 .NET 调用将检索类型为您提供的信息。
由于您正在查看 TraceSources,因此我鼓励您在 codeplex 上查看此项目:
http://ukadcdiagnostics.codeplex.com/
这是一个不错的项目(基于 TraceSource),它允许您以与使用 log4net 和 NLog 类似的方式格式化日志输出。
我还鼓励你看看这个围绕来自 Castle 的 TraceSource 构建的日志记录包装器。
https://github.com/castleproject/Castle.Core/blob/master/src/Castle.Core/Core/Logging/TraceLogger.cs
他们所做的有趣的事情是为 TraceSource 名称提供层次结构。我过去已经实现了类似的东西。效果很好。
我在这个问题中的回答提供了一个关于 TraceSource 层次结构如何有益的想法:
祝你好运!