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

Question

我已经使用Java编写了一个任务管理器程序，并在秋千中进行了单个UI实现。该程序目前有3层。通过用例控制器与域层交互的演示层，最后是用于持久性的技术服务层。此时，用户可以采取多种操作，例如添加任务，编辑任务状态等...在此方案中我的记录器的目的是跟踪用户采取的所有操作。因此，在一些地方，我可以调用记录器编写命令。我不会在演示层中进行任何登录，因为这将是一个可怕的设计决策，因此我要保留控制器，命令界面（实施以处理所有命令的执行，以实现撤消/重做函数），或在实际被操纵的较低级别的类中，例如任务类。

我认为控制器是一个相对不错的选择，因为它充当UI层和域之间的接触点，因此所有值得注意的命令最终都通过控制器，从而可以轻松验证所有重要的方法都被记录在记录中。不在控制器中不执行的原因是，它将减少凝聚力，增加耦合并可能导致腹胀控制器。

混凝土命令是另一个潜在的位置，因为它们也具有日志记录所需的所有信息。这将再次导致命令变得不那么凝聚并增加耦合。另外，如果我不使用命令接口对域对象采取操作，那么我会丢失记录。

最后，这导致我在较低级别域对象方法中实现记录器。这是一个很好的候选人，因为如果使用该程序，并且所有所需的信息都可以使用，始终会发生记录。唯一的负部分是，logger命令将稀疏地散布在较低级别的域对象中，从而使确保所有正确的方法都被记录起来更加困难。

我很想就此决定进行辩论，并感谢您的所有评论。

Answer 1

首先考虑实用性。伐木通常是维护和管理问题。设计中的每一层都是伐木的候选者，但出于某种原因。

不知道您的对象层次结构和设计...

从域到UI，每一层都是上一层的抽象或行为集合。您必须问自己，例如您要寻找什么水平的粒度？看到命令的记录会很有用吗？查看每个关联域层调用的记录也很有用吗？破译域调用并将其与特定命令相关联可能并不总是那么容易。