jfaiga (6) [Avatar] Offline
#1
I am in the middle of reading your book. I am finding it extremely well written, and a pleasure to read.

In the book it recommends that only the Composition Root knows about the IOC Container.
(ie only in exe's, test code, and website global asax)

I am using Castle Windsor and NLog.

Castle Windsor has a ILogger defined in its Castle.Core.dll that can be used that wraps NLog. In order to use it all projects that have logging would have to reference Castle.Core.dll.
Do you think it would be better to use the Castle Core ILogger, or use my own that does the same thing?

Additionally, where do you recommend that auto installers be put? It seems to be that each assembly that has concrete types would generally have its own reference to Castle.Core.dll due to its Installer.

In am swaying towards letting each of the csproj's having a reference to the Castle libraries...
mark.seemann (383) [Avatar] Offline
#2
Re: References to Castle.Core.dll
Thanks for writing - I'm happy to hear that you like the book smilie

I'm quite serious when I state that only the Composition Root should have a reference to a DI Container. If a DI Container is added to each and every other library, it's very likely that the container itself will insinuate itself more and more into that library's code and functionality. You probably don't want that.

Now, if there was a good reason to add a DI Container to each and every library, one could consider doing it anyway. It's always a question of advantages and disadvantages. However, there's really no good reason to do this.

When it comes to something like ILogger, I can think of at least two superior alternatives.

The first one is easy: just define your own IMyOwnLogger (or something similar) interface and implement an Adapter around Castle's built-in logger. That should be about 10 lines of code in total, for which you gain proper decoupling. I consider that an excellent return of investment.

An even better alternative is to not treat logging as a dependency at all. See e.g. http://stackoverflow.com/a/1709048/126014 and http://stackoverflow.com/a/8427915/126014

When it comes to installers, they should go in the Composition Root as well. Why would you want to put them in each library? You might need to configure library types differently depending upon in which application you want to use them.

Remember: a DI Container is an application-specific infrastructure component; a library should not concern itself with infrastructure.

HTH
jfaiga (6) [Avatar] Offline
#3
Re: References to Castle.Core.dll
Thanks, I'll look into the Cross Cutting Concern approach.

Regarding IMyOwnLogger:
In order to not have all the libraries not dependant on neither NLog nor Castle Windsor, it seems to me that I would have to create my own ILogger,Logger,LoggerFactory & LoggerManager.
Plus there would be at least a line for each ILogger method.
How do you get to 10 lines? Am I missing something?

Regarding why to put an installer in each library:
If I have many stand alone exes, plus services, plus a website, then I think most of the installer code would be similar between them. Maybe it requires special installer projects?
mark.seemann (383) [Avatar] Offline
#4
Re: References to Castle.Core.dll
IIRC, Castle's ILogger interface contains two methods. If you create a similar interface, you have two new lines of code. An Adapter from IMyOwnLogger to castle's logger would be require you to inject Castle's Logger into the Adapter and delegate each method call to the adapted Logger. That's what? Six lines of code?

Why would you need LoggerFactory and LoggerManager?

When it comes to registering components in many apps, perhaps you'll need to configure some of them differently - e.g. with different lifetimes, or various different primitives or connection strings or whatnot. That's done by the application, not the library.

If that seems like to much work, consider a more convention-based approach.

HTH
jfaiga (6) [Avatar] Offline
#5
Re: References to Castle.Core.dll
I am trying to understand what you mean that Castle's logger has only two methods.

As far as I can tell "Castle.Core.Logging.ILogger" has 7 methods per severity level, plus CreateChildLogger, which makes it 7 * 5 +1 = 36 methods.
mark.seemann (383) [Avatar] Offline
#6
Re: References to Castle.Core.dll
Right, I may have looked at another ILogger earlier...

Still, do you need all those 36 methods in your application code?