Question

为了清楚起见，我对'aspect'的含义是应用程序函数的水平因素，而不是像面向方面编程那样拦截所有方法调用。

我刚刚发现了.NET Trace基础架构的美妙之处，特别是TraceSource对象。像我这样的菜鸟，我给每个类都有自己的TraceSource，跟踪方法的开始和结束，错误等等。

但是，现在，我认为每个方面有一个TraceSource更好。例如。我有一个应用程序，可以在停车场内导入车辆移动记录，计算停车费用，然后将消息发送到计费系统（WHMCS）。

我想我应该有一个包含一堆静态TraceSource属性的类，如下所示：

public static class Traces
{
    static Traces()
    {
        VehicleMovements = new TraceSource("VehicleMovements", SourceLevels.All);
        Pricing = new TraceSource("Pricing", SourceLevels.All);
        Calculation = new TraceSource("Calculation", SourceLevels.All);
        Billing = new TraceSource("Billing", SourceLevels.All);
    }
    public static TraceSource VehicleMovements { get; set; }
    public static TraceSource Pricing { get; set; }
    public static TraceSource Calculation { get; set; }
    public static TraceSource Billing  { get; set; }
}

这样，我可以这样做，例如我发现该场景的任何类中的Traces.Pricing.VehicleMovements ("Terminal Id not configured");，并且具有更好的分组和更具凝聚力的日志或其他输出。

这是个好主意吗？对于奖励，一些关于追踪策略和模式的资源的指针将是非常好的，谢谢。

Answer 1

对不起，这将是一个程序员SE更多的答案。您显示的特定代码是基于主题的跟踪的一个很好的示例，而不是基于类的跟踪。如果它的好坏取决于你试图产生什么样的故事，如果那个故事提供了你需要的信息来理解问题并找到错误。

我得到了“痴迷”的痕迹并且在我读完一本书之后开始追踪所有内容，其中作者采访了一些着名的开发人员，并询问他们如何调试 - 几乎所有人都说他们回到某种写入消息屏幕在战略要点。所以可能/应该有一种方法来形式化这种做法，对吗？

所以我开始使用System.Diagnostics--它的主要优点是它始终可用。它是一个有缺陷的API，nLogger和log4net是更优雅的API。但是System.Diagnostics是可扩展的并且修复了许多缺陷 - 我总是将System.Diagnostics和一些自己的自定义监听器与Essential.Diagnostics和Ukadc库一起使用。

面向方面的跟踪 这意味着在每次方法调用之前和之后添加跟踪语句。这非常繁琐，并且在出错时，它提供的信息大多与堆栈跟踪相同。使用此策略进行大多数性能跟踪，以找出哪些方法被调用太多次，或者哪些方法在单个调用中消耗了太多时间或者集体消耗了多少时间。

基于类的跟踪 Trace变得很健谈。在微软，他们称之为“Spew”的网页，如果没有特别的想法进入跟踪的内容，它可以作为呕吐物提供信息。这是每个类一个TraceSource的动机，因此您可以为您关注的一个或两个类打开跟踪。

主题基础跟踪 我尝试每个类使用TraceSource，但我发现我的应用程序（以网络应用程序为中心的数据库）确实需要基于主题的跟踪。所以我有“perf”，“http”，“data”，“sql”和“app”的跟踪源。 Perf与执行时间有关，http是关于请求和响应的信息，数据在我得到数据时将数据转储到屏幕上，sql将sql +参数转储到屏幕上。在我的工作流程中，我一直打开主题基础跟踪，并且通常关闭类基本跟踪，除非存在特定问题。

生产/测试团队跟踪 跟踪和错误记录有很多重叠。 Trace讲述了这个故事，错误记录说明出了什么问题。跟踪收集起来可能很昂贵，但如果我发现错误的时间发生错误，有时这很有用。目前，在生产中我将跟踪写入内存，然后通过电子邮件错误报告包含该跟踪。生产跟踪和错误记录必须更精细地调整开发跟踪，因为过度喷射会产生更严重的后果，例如，由于记录不重要的问题，坏的perf或dev-ops团队忽略了错误日志中的重要错误。

这是我在撰写有关跟踪http://suburbandestiny.com/Tech/?p=640的一些规范性指南时写的关于Trace的博客文章，因为API的常见建议就像跟踪一样（此API非常强大，您可以将其用于你想要的任何事情！实际上并不是所有的能力。

Answer 2

在Essential.Diagnostics项目的文档中，其中包含一组扩展System.Diagnostics（TraceSource）的侦听器，我有几页指导。（我参与了Essential.Diagnostics项目）

我不会在这里重现整个文档，但会尝试提供一个摘要，以便答案可以单独使用。

（1）跟踪级别 - 可能总是希望跟踪评级为“严重”，“错误”和“警告”的消息，甚至可能写入类似Windows事件日志的消息，并且可能无法关闭。

在信息层面，有一些全球性事件，例如服务已启动，您始终要记录以及每个事务事件，这些事件可能具有自己的自定义（高度结构化）应用程序日志文件（例如IIS日志）。您的代码应确保错误报告，应用程序日志和较低级别跟踪之间存在一致性（否则会引起混淆）。

下面是所有详细的东西 - 此时它可能很多，单个开/关开关不是很有用;你真的需要一些方法来打开/关闭各个部分。基于分层的日志记录（例如log4net或新的Microsoft.Extensions.Logging）对此有好处，但是对于不同的程序集/命名空间/主题，有六个单独的TraceSource通常可以手动完成。（如果你下到班级，明确支持层次结构是有用的。）

关键是你需要能够打开/关闭详细日志记录的各个部分，或者其他一些过滤方式，以使其有用。（另一种选择是将所有内容写入Seq，例如使用Essential.Diagnostics.SeqTraceListener，然后过滤您感兴趣的内容。）

更多细节：https://essentialdiagnostics.codeplex.com/wikipage?title=Logging%20Levels&referringTitle=Guidance

（2）事件ID理论 - 另一个主要指导是基于早期的互联网RFC和＃34;回复代码理论＆＃34 ;;如果您使用过Web / HTTP，那么您通常会计算出400和500条消息是错误的。我认为有管理事件ID，特别是信息级别＆amp;上面（但不是详细）是一个很好的功能。 System.Diagnostics支持这一点，我在Essential.Diagnostics中使用的流畅界面使它更容易一些。新的Microsoft.Extensions.Logging还包括对事件ID的良好支持，但其他框架（log4net，NLog等）可能有点笨拙。

更多详情：https://essentialdiagnostics.codeplex.com/wikipage?title=Event%20Ids&referringTitle=Guidance

“基于方面的追踪”有什么优点吗？

2 个答案: