How to access application level objects (ie. logger, container, unit of work) ?

Question

What is the best practice on setting and keeping these "global" objects ?

I have encountered this problem couple of times with

• ORM session object (XPO from DevExpress)

• IOC container (Microsoft.Unity)

• Logger (from The Object Guy)

I have come up with three options on how to deal with this:

1. Dependency injection. This looks extremely cumbersome to me and I feel like every class is bloated by extra three getters/setters that all almost all the classes would use. On the other hand it gets rid of the global variables fear and makes the code bits less dependant of each other.

2. Create a static class (for example ContainerKeeper) that is settable once and returns the kept object. I know this resembles a singleton and I should use singleton instead.

3. Using a Singleton pattern. I've read some discussion against the use of singletons and how bad they are etc. so I am frankly unsure how many principles of good OO design will I break by using one in these cases.

So my question rephrased is :

Is there some other option, Am I completely off the track ? How would you do it ?

Answer 1

I usually use dependency injection, that would be option 1. But instead of using constructor parameters for injection I usually use properties. This cleans up my constructors. I use Castle Windsor as an IoC container. It allows me to move setup code from the constructor to an Initialize method that is called after all dependencies are set whenever I implement an IInitializable interface. But my guess is that Unity also supports something like this.

Option 2 and 3 would not be optimal. By calling statics you tie your code to implementations of the classes it depends on. Having them injected only ties your code to the interface of the dependencies.

---

You do need the container object. But usually only at the highest level. Dependencies of dependencies etc. are resolved automatically, castle windsor does this and i'm pretty sure unity does this too. I normally don't use the IoC container for objects that need to be constructed on the fly so I don't often need to have a reference to the container on lower levels. When I do need this there are some tricks where you can have the container inject itself into classes that depend on it. Got to write a blog post on this. I'll let you know when it is done.

Answer 2

I would put them behind a interface of your own design and call global instances. That way you are not tied to that particular implementation. You clearly define what it is about those services are are using. Finally avoid having to clutter those classes.

Like anything it is a judgment call. Make sure tho that what you are making global is truly a global service. For example the Logger is definitely a good candidate.