「基於Aspect的追蹤」有什麼優點嗎？

爲了清楚起見，我的'aspect'的含義是應用程序函數的一個橫向因素，而不是像面向方面編程那樣攔截所有的方法調用。「基於Aspect的追蹤」有什麼優點嗎？

我剛剛發現了.NET跟蹤基礎結構的美妙之處，尤其是TraceSource對象。就像我在這裏的noob，我給每個類別自己的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");我發現這種情況，並有一個更好的分組和更有凝聚力的日誌或其他輸出。

這是個好主意嗎？對於獎金，一些指向追蹤策略和模式的資源將非常好，謝謝。

來源

2013-06-13 ProfK

對不起，這將是更多的程序員SE的答案。您顯示的特定代碼是基於主題的跟蹤的一個很好的示例，與基於類的跟蹤相反。如果它的好壞取決於你想要創造什麼類型的故事，並且如果這個故事提供了你需要了解的信息並找到問題。

我得到了「癡迷」的痕跡，在我讀了一本書後，我開始追蹤一切，作者採訪了一羣着名的開發人員，並問他們如何調試 - 幾乎所有人都說他們回到某種書寫消息在戰略點的屏幕。所以可以/應該有一種方法來正式化這種做法，對嗎？

所以我開始使用System.Diagnostics--它的主要優點是始終可用。這是一個有缺陷的API，nLogger和log4net是更優雅的API。但是System.Diagnostics是可擴展的並且修復了很多缺陷 - 我總是將Essential.Diagnostics和Ukadc庫與System.Diagnostics以及我自己的一些自定義偵聽器一起使用。

Aspect Oriented Trace 這意味着在每個方法調用之前和之後添加跟蹤語句。這非常瑣碎，並且在錯誤的地方，它提供了與堆棧跟蹤相同的信息。大多數使用此策略的性能追蹤可以找出哪些方法被調用的次數太多，或者哪些方法在單次調用中或集體中耗費了太多時間。

基於類的跟蹤 跟蹤變得非常快速。在微軟，他們稱之爲「Spew」的痕跡，如果沒有特別的想法追溯到什麼時候，它可能是嘔吐物。這是每個類一個TraceSource的動機，因此您可以爲您關心的一個或兩個類啓用跟蹤。

主題基道 我試圖用每類TraceSource，但我發現，我的應用程序（DB爲中心的web應用程序）真的需要根據主題跟蹤。所以我有一個「perf」，「http」，「data」，「sql」和「app」的跟蹤源。Perf與執行時間有關，http是關於請求和響應的信息，數據將數據轉儲到屏幕上，sql會將sql +參數轉儲到屏幕上。在我的工作流程中，我總是打開主題庫跟蹤，並且通常會關閉類基本跟蹤，除非存在特定問題。

生產/測試團隊跟蹤 跟蹤和錯誤記錄有很多重疊。跟蹤講述故事，錯誤日誌記錄說明出了什麼問題。跟蹤收集起來可能很昂貴，但如果我發現有錯誤發生，那麼有時候這很有用。目前，在生產中，我會將跟蹤信息寫入內存，然後通過電子郵件發送錯誤報告來包含該跟蹤信息。生產跟蹤和錯誤日誌記錄必須更精確地調整開發跟蹤，因爲對過多的溢出產生更嚴重的後果，例如錯誤的性能或dev-ops團隊由於記錄了不重要的問題而忽略錯誤日誌中的重要錯誤。

這裏是一個博客帖子我寫的關於跟蹤，當我試圖爲跟蹤http://suburbandestiny.com/Tech/?p=640制定一些規範性準則，因爲API的喜歡跟蹤的共同建議（此API是如此強大，你可以用它來什麼你想到！）實際上並不是所有的權力。

來源

2013-06-13 11:29:24 MatthewMartin

跟蹤可能是一個有缺陷的API，但它始終存在。您可以使用NLog和log4net的形式添加更精細的組件，但Trace始終存在，即使只是控制檯或文本文件。 – ProfK

我們處於暴力協議中:-)，我已經在上面提及了這一點。 – MatthewMartin

在Essential.Diagnostics項目的文檔中，其中包含一系列擴展了System.Diagnostics（TraceSource）的偵聽器，我有幾個關於指導的頁面。（我參與Essential.Diagnostics項目）

我不會在這裏複製整個文檔，但會嘗試給出一個總結，以便答案可以獨立。（1）跟蹤級別 - 評級爲嚴重，錯誤和警告的消息可能總是要跟蹤，甚至可能寫入類似Windows事件日誌的東西，並且可能無法關閉。

在信息級別上有一些全局事件，例如，服務開始，您始終想要記錄日誌以及每個事務，這些事件可能有自己的自定義（高度結構化）的應用程序日誌文件（例如IIS日誌）。您的代碼應確保錯誤報告，應用程序日誌和低級別跟蹤之間保持一致（否則會令人困惑）。

下面是所有詳細的東西 - 在這一點上它可以很多，一個開/關切換不是很有用;你真的需要某種方式來打開/關閉各個部分。基於分層的日誌記錄（如log4net）或新的Microsoft.Extensions.Logging對此非常有用，但對於不同的程序集/命名空間/主題，通常有六個單獨的TraceSource可以手動操作。（如果你到了課堂級別，明確支持層次結構是有用的。）

關鍵的一點是，你需要能夠打開/關閉詳細日誌記錄的某些部分或其他方式來過濾它是有用的。（另一種選擇是編寫使用Essential.Diagnostics.SeqTraceListener一切類似序列，例如，然後篩選你所感興趣的東西）。

（2）事件ID的理論 - 另一個主要指導原則是基於早期的互聯網RFC「回覆代碼理論」;如果你使用過Web/HTTP，那麼你通常會處理400和500條消息是錯誤的。我認爲管理事件ID，特別是上面的信息級別&（但不適用於詳細）是一個很好的功能。 System.Diagnostics支持這一點，而Essential.Diagnostics中的流暢接口使它更容易一些。新的Microsoft.Extensions.Logging還包含對事件ID的良好支持，但其他框架（log4net，NLog等）可能有點笨拙。

來源

2017-02-10 03:32:11

「基於Aspect的追蹤」有什麼優點嗎？

回答

相關問題