使用记录器最有凝聚力的位置是什么？
我已经使用 Java 编写了一个任务管理器程序，并暂时实现了一个 UI 实现。该程序目前有 3 层。表示层通过用例控制器与域层交互，最后是用于持久性的技术服务层。用户此时可以执行多种操作，例如添加任务、编辑任务的状态等......在此方案中我的记录器的目的是跟踪用户执行的所有操作。因此，有几个地方可以调用记录器来编写命令。我不会在表示层中进行任何日志记录，因为这将是一个糟糕的设计决策，因此我只剩下控制器、命令接口（用于处理所有命令的执行，以实现撤消/重做功能） ），或者在实际被操纵的较低级别的类中，例如任务类。
我认为控制器是一个相对不错的选择，因为它充当 UI 层和域之间的接触点，因此所有值得注意的命令最终都会通过控制器，从而可以轻松验证所有重要方法是否都已记录。不在控制器中执行此操作的一个原因是，它将降低内聚性、增加耦合并可能导致控制器臃肿。
具体命令是另一个潜在位置，因为它们也拥有日志记录所需的所有信息。这将再次导致命令的内聚性降低并增加耦合。另外，如果我不使用命令界面对域对象执行操作，那么我会丢失日志记录。
最后，这引导我在较低级别的域对象方法中实现记录器。这是一个很好的候选者，因为如果正在使用程序并且所有需要的信息都可用，则始终会发生日志记录。唯一的缺点是记录器命令将稀疏地分散在较低级别的域对象中，这使得确保记录所有正确的方法变得更加困难。
我很乐意就此类决定进行辩论，并感谢您的所有评论。
I've written a task manager program using Java, and made a single UI implementation for the moment in swing. The program has 3 layers at the moment. A presentation layer that interacts with the domain layer via a use case controller, and finally a technical services layer used for persistence. There are several actions a user can take at this point, such as adding tasks, editing the status of a task, etc... The purpose of my logger in this scheme is to keep track of all actions taken by the users. So, there are a few places where I could invoke the logger to write a command. I will not be doing any logging in the presentation layer as this would be a terrible design decision and so I'm left with the controller, the command interface (implemented to handle the execution of all commands for the purpose of implementing undo/redo functions), or in the lower level classes that are actually being manipulated, say the task class for instance.
I think the controller is a relatively decent option for this as it acts as the point of contact between the UI layer and the domain, thus all notable commands ultimately pass through the controller making it easy to verify that all of the important methods are being logged. A reason not to do it in the controller is that it will reduce the cohesion, increase coupling and potentially lead to a bloated controller.
The concrete commands are another potential location as they too have all of the information needed for logging. This would again cause the commands to become less cohesive and increases the coupling. Also, if I don't use the command interface for taking an action on a domain object than I lose my logging.
Finally this leads me to implementing the logger in the lower level domain objects methods. This is a good candidate because logging will always occur if the program is being used and all of the information needed is available. The only negative part is that logger commands will be sparsely scattered amongst the lower level domain objects making it harder to ensure that all of the right methods are being logged.
I would love get a debate going about this type of decision and appreciate all of your comments.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先考虑实用性。日志记录通常是一种维护和维护工作。行政关注。设计中的每一层都可以进行日志记录，但原因有所不同。
在不真正了解对象层次结构和设计的情况下...
从域到 UI，每一层都是前一层行为的抽象或集合。您必须问自己一些问题，例如您正在寻找什么级别的粒度？查看命令的记录有用吗？查看每个关联域层调用的日志记录是否也有用？破译域调用并将其与特定命令关联起来可能并不总是那么容易。
Think about practicality first. Logging is often a maintenance & administrative concern. Each layer in your design is a candidate for logging, but for somewhat different reasons.
Without really knowing your object hierarchy and design...
Going from domain to UI, each layer is an abstraction or collection of behavior of the previous layer. You have to ask yourself things like what level of granularity are you looking for? Would it be useful to see a logging of a command? Would it also be useful to see logging for each associated domain layer calls? It may not always be easy to decipher domain calls and associate it with a particular command.