2010-02-09 91 views
1

日誌記錄應用程序塊是否能夠處理這些問題或它們的組合?企業庫日誌應用程序塊選項

  • 如果日誌記錄失敗,不拋出異常
    • 特殊例外情況/異常類型只
  • 如果日誌記錄失敗,退回到另一種類型(即數據庫日誌記錄失敗,回落到我的實際使用情況發電子郵件或網絡發送)

例子:

我正在爲我們的團隊寫票務系統。如果通過電子郵件向新團隊創建新故障單,則我希望它向異常/錯誤日誌報告該情況,但不會冒用戶名,無論日誌記錄堆棧中日誌記錄失敗的深度如何,用戶都不會需要一個錯誤信息,保存票證。一些錯誤地點/例外我想冒泡,但是我現在處理的大多數我不知道。

回答

3

我對ELLAB的經驗是,當它不起作用時,幾乎不可能找出原因。日誌記錄就是這樣一個依賴於像ELLAB這樣一個重量級組件的系統的(通常)輕而易舉的實現部分,它可能是一個非常痛苦的工作,有時是毫無意義的。

我已經使用了三種日誌記錄平臺--Log4Net,ELMAH和ELLAB - 並且已經推出了我自己的。 ELLAB依賴於EL的其他部分,並且需要重新啓動才能啓動並運行。 L4D L4N是ELLAB的瘦身版本,它更容易上手並提供等效的功能。 ELMAH是一個用於記錄網站錯誤的好庫。

我建議在ELLAB之前使用L4N,特別是如果您沒有使用任何其他EL塊。如果您嚴重依賴企業圖書館,ELLAB可能是您最好的選擇;如果沒有發生,祝你好運。網站一定要使用ELMAH。如果您正在編寫一個較小的應用程序,請考慮滾動您自己的日誌代碼。

+0

我還沒有在企業庫中做過任何事情,每當我看到我想嘗試的東西時,我就跳入EL是艱難的潮流,研究評論和比較,並且看到評論者認爲另一個框架更加健壯和更容易對於特定的塊 – Maslow 2010-02-16 19:58:41

+1

企業庫的理念是,日誌記錄是應用程序的增值服務,因此日誌記錄過程中的任何失敗都必須適度地處理,而不會引發主要業務流程的異常。日誌記錄塊通過將所有日誌記錄失敗發送到一個名爲記錄錯誤和警告的特殊類別來實現此目的。默認情況下,這些錯誤消息被寫入Windows事件日誌,但您可以將此類別配置爲使用不同的跟蹤偵聽器寫入其他目標(如果您願意)。 – 2011-04-11 15:04:29

+0

至於依賴性,唯一的DLL LAB取決於有這些:Microsoft.Practices.EnterpriseLibrary.Common.dll Microsoft.Practices.Unity.dll Microsoft.Practices.Unity.Interception.dll Microsoft.Practices.ServiceLocation.dll 這是EntLib管道的核心。 – 2011-04-11 15:05:20

1

我使用ELMAH進行網絡日誌記錄,並使用EL記錄模塊進行其他任何操作。我發現EL記錄塊非常靈活,可以完成你所要求的功能。

我會將日誌邏輯包裝到某個日誌記錄類中,並處理異常情況如何處理。

+0

在我希望回退到其他系統的情況下,這種方式會如何工作,您是否可以在同一個應用中使用多個EL日誌記錄塊?或者它會導致主要的.config文件意大利麪? – Maslow 2010-02-16 19:57:16

2

如果記錄不扔你可以使用類LoggingInstrumentationProvider的failureLoggingError事件是這樣的:

LoggingInstrumentationProvider instrumentation = Logger.Writer.GetInstrumentationEventProvider() as LoggingInstrumentationProvider; 

instrumentation.failureLoggingError += (s, z) => { throw z.Exception; }; 

.... 

.... 

//Logging code 

Logger.Write(new LogEntry() { Message = "bla bla", Severity = TraceEventType.Critical}); 
+0

由於logger.writer沒有方法GetInstrumentationEventProvider,我無法獲取檢測的參考。這是企業圖書館5嗎? – 2013-09-04 06:34:05

3

馬斯洛,請閱讀我的意見,其他答覆。另外,我強烈建議您閱讀開發人員指南的這一章 - As Easy As Falling Off a Log

我不會建議推出自己的日誌記錄基礎架構。爲什麼不使用你不需要維護的成熟的東西,而是專注於你的應用的業務邏輯?

相關問題