什么是使用记录器最有凝聚力的位置？

Question

我已经使用Java编写了一个任务管理器程序，并在摆动的瞬间制作了一个UI实现。该计划目前有3层。表示层通过用例控制器与域层交互，最后是用于持久性的技术服务层。在这一点上用户可以采取多种措施，比如添加任务，编辑任务的状态等等。我的记录器在此方案中的目的是跟踪用户采取的所有操作。所以，有几个地方我可以调用记录器来编写命令。我不会在表示层做任何日志记录，因为这将是一个可怕的设计决定，所以我留下了控制器，命令接口（实现处理执行撤消/重做功能的所有命令的执行），或者在实际被操纵的较低级别的类中，比如说任务类。

我认为控制器是一个相对体面的选项，因为它充当UI层和域之间的接触点，因此所有值得注意的命令最终都会通过控制器，从而轻松验证所有重要的方法正在被记录。在控制器中不这样做的一个原因是它会降低凝聚力，增加耦合度并可能导致控制器臃肿。

具体命令是另一个潜在的位置，因为它们也具有记录所需的全部信息。这将再次导致命令变得不那么内聚并且增加了耦合。此外，如果我不使用命令界面对域对象执行操作，则会丢失日志记录。

最后，这导致我在较低级别的域对象方法中实现记录器。这是一个很好的选择，因为如果程序正在被使用并且所有需要的信息都可用，日志记录就会一直发生。唯一的负面部分是记录器命令将稀疏地分散在较低级别的域对象中，这使得难以确保记录所有正确的方法。

我很想得到关于这种类型的决定的辩论，并感谢您的所有意见。

Answer 1

首先考虑实用性。日志记录往往是一个维护管理问题。设计中的每个层都是日志记录的候选人，但原因有所不同。

没有真正了解你的对象的层次结构和设计...

从域名到UI去，每一层是前一层的行为的抽象或集合。你必须问自己，比如你在寻找什么级别的粒度？看到命令的日志会有用吗？查看每个关联的域图层调用的日志记录也很有用吗？解密域名调用并将其与特定命令关联并不总是很容易。