什麼是使用記錄器最有凝聚力的位置？

Question

我已經使用Java編寫了一個任務管理器程序，並在擺動的瞬間製作了一個UI實現。該計劃目前有3層。表示層通過用例控制器與域層交互，最後是用於持久性的技術服務層。在這一點上用戶可以採取多種措施，比如添加任務，編輯任務的狀態等等。我的記錄器在此方案中的目的是跟蹤用戶採取的所有操作。所以，有幾個地方我可以調用記錄器來編寫命令。我不會在表示層做任何日誌記錄，因爲這將是一個可怕的設計決定，所以我留下了控制器，命令接口（實現處理執行撤消/重做功能的所有命令的執行），或者在實際被操縱的較低級別的類中，比如說任務類。

我認爲控制器是一個相對體面的選項，因爲它充當UI層和域之間的接觸點，因此所有值得注意的命令最終都會通過控制器，從而輕鬆驗證所有重要的方法正在被記錄。在控制器中不這樣做的一個原因是它會降低凝聚力，增加耦合度並可能導致控制器臃腫。

具體命令是另一個潛在的位置，因爲它們也具有記錄所需的全部信息。這將再次導致命令變得不那麼內聚並且增加了耦合。此外，如果我不使用命令界面對域對象執行操作，則會丟失日誌記錄。

最後，這導致我在較低級別的域對象方法中實現記錄器。這是一個很好的選擇，因爲如果程序正在被使用並且所有需要的信息都可用，日誌記錄就會一直髮生。唯一的負面部分是記錄器命令將稀疏地分散在較低級別的域對象中，這使得難以確保記錄所有正確的方法。

我很想得到關於這種類型的決定的辯論，並感謝您的所有意見。

Answer 1

首先考慮實用性。日誌記錄往往是一個維護管理問題。設計中的每個層都是日誌記錄的候選人，但原因有所不同。

沒有真正瞭解你的對象的層次結構和設計...

從域名到UI去，每一層是前一層的行爲的抽象或集合。你必須問自己，比如你在尋找什麼級別的粒度？看到命令的日誌會有用嗎？查看每個關聯的域圖層調用的日誌記錄也很有用嗎？解密域名調用並將其與特定命令關聯並不總是很容易。