OT: Separation of Concerns-related Design Decision

[Smithers]

I'm writing a utility app that installs stuff (copies files to folders,
installs assemblies to the GAC, executes scripts gainst a SQL Server
database, etc).
As part of the design of this utility, I'm breaking out specialized
"installers" into their own assemblies (.dll). So one "installer assembly"
will take care of GAC installations, while another executes scripts against
the SQL Server. The hosting application will enable the user to specify
various installation options that are passed to the "installers" at runtime.

Of course I want for a log (simple text file) to be updated for each
installatoin operation, with associated success/failure outcome, date time,
etc data.

The question here has to do with "where to implement the logging feature?" I
see two reasonable options.

1. Each "installer assembly" can take care of its own logging.

2. The "installer assemblies", instead [of logging], raise events containing
the data that would otherwise get logged. The hosting application would then
respond to the events and write the data to the log fil, optionally ignore
the event data, or display the event data to the user (in addition to
logging), etc.

What would you consider to be the better alternative - and why?

Thanks!

 

[Nicholas Paldino [.NET/C# MVP]]

Smithers,

Personally, I prefer #2, as you pretty much reduce the amount of code
you would have to replicate if you left logging to each installer assembly.
You could simply expose the logging service as a singleton which exposes the
functionality you need, and then each installer assembly would access that
singleton to perform logging.