2010-03-03 63 views
3

我想在幾個實用程序類別中採用日誌記錄, G。 DBI。 Log :: Log4perl的最佳做法是什麼?在實用程序類別中記錄

我認爲可以繼承DBI(比如說MyDBI)並覆蓋那裏的一些方法來使它們執行日誌記錄。但是類別存在問題。如果創建

Log::Log4perl->get_logger(ref $self || $self) 

一個記錄器,那麼所有的日誌條目屬於MyDBI,這將是很難過濾。所以對我來說,傳遞一個記錄器到MyDBI來自調用模塊(比如說,MyModule)似乎更好,因此這個類別在語義上是正確的。第一個問題,一般情況下可以嗎?我的意思是,這種方法有沒有隱藏的礁石?

第二個問題,如何將記錄器傳遞給MyDBI?我有一個想法來聲明一個全局變量,例如。 G。 $MyDBI::logger並在撥號方式中設置:

local $MyDBI::logger = Log::Log4perl->get_logger(ref $self || $self); 

傳統的全局變量不喜歡。你能想出更好的方法嗎?

編輯:當然,最好的代碼是沒有代碼。如果考慮到繼承,那麼caller就足夠了。

第三個問題是否可以使用Log :: Log4perl登錄到兩個類別MyDBIMyModule,如果它們在層次上不相關?

回答

2

我強烈建議您在每個函數或每個模塊的單獨記錄器中獨立記錄調用者,以便可以獨立於調用者中使用的log4perl運行模塊。 每個模塊都將創建自己的記錄器Log::Log4perl->get_logger("module name")
如果調用者沒有創建任何appender,程序將不會記錄任何內容,並且模塊中的log4perl將從功能性立場中被忽略。
Log4Perl實現了一個用於創建記錄器的單例模式,它與全局變量相似。
您的日誌記錄應儘可能細化,並根據經驗法則登錄調試任何輸入參數和任何函數/方法的結果。如果真的有必要,您還可以使用堆棧跟蹤來找出導致錯誤情況的調用者。將它添加到參數中只會增加額外的複雜性。

以下配方可能會給您更多關於log4perl配置方面靈活性的想法。 Log4Perl Recipes對我來說,整個想法是保持代碼不變,並根據我實際的日誌記錄/錯誤跟蹤要求(將來可能會改變)來更改日誌記錄配置。如果可能的話,保持代碼不變,對於模塊更重要,因爲您希望避免測試所有調用程序。

簡要回答你的問題。 1.)每個模塊應該有自己的記錄器 2.)因此,不要將記錄器添加到接口 3.)Log4Perl將根據您的appender配置登錄所有級別。這樣你就可以控制你看不到的東西 - 正常級別通常是INFO,特定的模塊可能在調試中。在不好的情況下,模式佈局將允許您僅使用配置將堆棧跟蹤添加到日誌記錄中。

+0

不好意思,我還沒有理解第一句話。 「呼叫者」,「獨立於log4perl運行你的模塊」是什麼意思?你能否讓它更明確? – codeholic 2010-03-09 17:31:24

+0

例如在編寫測試類時,你可能會創建一些模塊,這些模塊不一定會實現log4perl--你可以簡單地跳過它,而如果你的界面是你的邏輯部分,你需要添加大量的邏輯。 – weismat 2010-03-09 18:58:31