設計應用程序範圍的日誌記錄系統有哪些準則？

Question

我現在正在學習分層架構，我想知道如何在這樣的設計中添加日誌記錄系統。

現在讓我們說我們有三個層次：

1. 表示層
2. 業務層
3. 數據訪問層

，並假定只有更高級別的層意識到層低一級。例如，表示層意識到業務層，但不是相反。

你應該在哪裏實現一個通用記錄器類？

1. 如果我在一個不同的項目中實現它，這意味着所有的圖層都依賴於一個普通的程序集，這可能會或可能不是很好。雖然這可以通過依賴注入來克服。
2. 如果我在最高級別（在本例中是表示層）實施它，它將違背單一職責原則。

什麼是實現日誌機制的好地方？

在實現它之後，使用這樣一個系統的方法是什麼？

1. 它應該理想地能夠捕獲未捕獲的異常並將異常描述保存在某處。
2. 你應該在哪裏捕捉異常？他們是否應該陷入最高層（表現層）？還是應該在其他地方抓到它們？
3. 什麼是使用傳遞記錄到一個類的方式？在接受類似​​這樣的接口的項目中添加方法/構造函數重載是否有意義？

正如您所看到的，我對這個主題感到困惑，在我目前的工作中，沒有人對企業應用程序設計/分層設計有所瞭解，儘管他們正在設計企業應用程序。因此，任何幫助我向正確的方向，將不勝感激。

Answer 1

伐木是一個橫切關注。這意味着它包含了您的架構的所有層，將它作爲單獨的庫實現是有意義的。但是，這僅僅是一個練習，因爲已經有很好的解決方案，比如Log4Net，NLog，甚至.NET自己的TraceSources。

我傾向於支持那些支持分層日誌記錄的應用程序（例如log4net）。這使得在生產系統中配置所需的跟蹤級別變得更容易。例如。您可以將MyApp.SomeNamespace的一般跟蹤級別設置爲Warning，但也可以將特定類型設置爲MyApp.SomeNamespace.AnInterestingClass至Debug。

我不確定我是否理解「使用這樣的系統的方式是什麼」部分。

您可以在任何需要的地方，在您的應用的所有圖層中，在需要它的每種方法中使用日誌記錄。我的印象是，你有一個集中的地方，所有的錯誤處理和記錄的想法，但這些是分開的事情。

它應該理想地能夠捕獲未捕獲的異常並將異常描述保存在某處。

不，不應該。記錄器寫東西到日誌，他們不處理異常。記錄不僅用於報告錯誤。您還需要記錄應用程序的執行情況和許多內部信息（但具有不同的跟蹤級別），以便在生產或事後分析中對系統進行故障排除。

您應該在哪裏找到異常？

在各級。代碼中的許多方法將處理與當前上下文相關的異常。我想你真的想知道在哪裏處理那些其他地方沒有捕獲到的異常 - 某種全能處理程序。爲此，通常最有意義的做法是在最上層，即在.exe中，或者更通常地，在包含表示應用程序本身的類型的層中。有很多方法可以做到這一點 - 從簡單地將處理程序註冊爲未處理的異常（ThreadException/UnhandledException）到HandleError/Application_Error in ASP.NET MVC，直至使用我個人不喜歡的（如大多數企業庫）的exception handling application block之類的東西。

什麼是使用傳遞記錄到類的方式？將方法/構造函數重載添加到接受像ILogger這樣的接口的項目中的所有內容是否有意義？

這取決於您的實施。看起來你想要依賴注入路徑。由於記錄器不是必需的依賴項（即它與類型的功能行爲無關，而是與實現有關），所以我寧願通過屬性注入來處理它作爲可選的依賴項，而不是通過構造函數進行處理，IMO，應該只能用於主要依賴關係 - 類型正常運行所需的依賴關係。

但是，您可能不想使用DI。那麼你需要一些其他的方式來記錄。一種選擇是討論here。