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.
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.