2013-02-08 141 views
4

由於我目前在我的(Asp.Net Web Api)應用程序中設置日誌,因此我正在閱讀有關日誌記錄的最佳實踐。我來到這個關於logging best practices的問題。日誌記錄框架與System.Diagnostics跟蹤

我是去NinjectLogging ExtensionsNlog/Log4Net的方式,但這個問題(或者我應該說答案)讓我第二次想到。

目前我啓用了跟蹤功能,記錄每一處在那裏,感覺有點混亂,讓日誌和痕跡不能疊加在一起。

我認爲,當我切換到診斷跟蹤並建立在框架已經給我的東西之上時,我最終會得到更完整的跟蹤。描述完整故事的軌跡對我來說聽起來更有用,然後是單獨的軌跡和日誌,它們都知道故事的一部分。當然,我總是可以再次與聽衆和過濾器分開。

但在另一方面,我總是瞭解到:

記錄=跟蹤

因此,這讓我的問題,我應該放棄日誌框架,它的啓動階段項目,還是應該堅持下去?

如果我放棄日誌框架,我應該使用一個接口,以防萬一我們想再次切換到另一個日誌/跟蹤框架,或者我可以只依賴System.Diagnostics?

回答

7

我試過了Log4NET的路徑,看着Ninject。

從我發現的情況來看,我認爲將Diagnotisics.Trace轉換爲日誌框架比嘗試處理我發現的任何日誌框架的權重要有效得多。 (並且我同意跟蹤!=記錄)

也許我是一個控制怪胎,但我不想將大量意見引入到我的代碼庫中。我需要工具,而不是緊身衣。

構建跟蹤到日誌框架還有一些工作,但它是高度可重用的,因爲它只是核心診斷DLL,您可能已經在您的程序中,如果沒有別的,然後秒錶的時間。

無論如何,只是我的看法,但我更喜歡Diagnostics.Trace路線。 想想看:http://www.codeproject.com/Articles/2680/Writing-custom-NET-trace-listeners - 這是舊的,但會告訴你什麼是必要的推出自己的。

+0

感謝您的回答。我這樣走了,並沒有在任何時候後悔。我使用common.logging並編寫了一個適配器,它適合我的診斷跟蹤跟蹤記錄需求。生成的日誌非常有用,可讀性強,易於使用。 – 2013-07-11 11:07:53