I have a the requirement for a webservice which should return a "business log" of the action the service performed. Usually I only return error logs which are based on exceptions. the exceptions get aggregated to a log at the top most level in the webservice.

Injecting a logger-object into every business class so it could write to the "business log" seems to be a solution, but it pollutes my code with a lot of logging-commands inside the business code. Also every constructer has to be modified. Adding an attribute to every class which includes the log messages also looks strange to me. Is there any other solution?

2 Answers 2


There's really not enough information about the expected contents of the business log. Generally, I see the following approaches:

  1. If the logging can be modeled as a cross-cutting concern, you could use some appropriate technology like an aspect framework or interceptors. (In Java that would e.g. be AspectJ or an interceptor in a CDI container)

  2. You could wrap the business classes with logging facades, which implement the same interface, perform the logging, and then delegate to the real business class.

  3. If none of these is appropriate (e.g. because you need real in-depth logging of each step a method takes) I cannot see any way without polluting your code with logs.


Your business logger needs to communicate with other out-of-process services for data storage. This means, you need to decouple this logger from your business logic, so you could easy mock it in unit tests or replace with another logger implementation based on the same logger interface, that will be expected in client code.

You wrote, that your logs are based on exception is thrown. This doesn't look correct solution for business logger, because you may want store log information regarding successful operations, provide "info" or "warning" priority logs additionally to "error" kind of records. You also may want to post more than one business log per single action.

You should distinguish between business logging and support logging, where business logs describe business processes and problems for clients of your application, but support logs provide information for developers and QA. It is often useless to decouple support log service to separate dependency, but you may want to separate it too.

  • 1
    thank you for your answer. the exceptions-topic is on how i handle error-logging usually. that works fine. but like you said thats not a solution for business logging. so you recommend injecting a business-logger-interface into every domain class constructor? and then using the same object-reference of the logger for every class, so I can get an aggregated log of the whole business process? Commented Mar 19, 2020 at 12:55
  • I see, you asked for alternative solution to simplify injecting of logger. It depends on your needs, and if you don't want to inject logger dependency via constructor, don't want to use injection container, you can have a trait (in php), that stores logger object dependency in its state. This trait will have setter method to inject dependency, and getter method to read dependency. Getter method may have lazy initialization of logger object. Setter-way DI isn't considered as a clean way, but it may work as intermediate stage of your code base refactoring. Don't you need to log in constructor? Commented Mar 19, 2020 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.