Consider a logging system - used absolutely everywhere in your codebase.

(note - logging is just an example, don't take it too literally and point me at your favourite logging system).

public interface ILogger
    void LogMessage(string message);

// Just used for testing, do nothing
public class NullLogger : ILogger
    public void LogMessage(string message) { }

public class FileLogger : ILogger
    public FileLogger(string fileName){...}
    public void LogMessage(string message) { 
        // Log to a file here 

No I could make every single class have ILogger in ctor or param and use some IoC framework.

Or I could just use something like

public static class Globals
   public static ILogger Log = new NullLogger();

Use at any point by Globals.Log.LogMessage("Hello Logging World");

And at 'Compositon Root' (main entry point of program) set Globals.Log = new FileLogger("somefile.log");

Or this could be done as a Singleton of course.

When is using DI and optionally IoC a step too far? What would you do in this case?

  • +1 good question, since it is much easier to ask for benefits or "when to use" of di/ioc.
    – k3b
    Jul 21, 2012 at 7:07
  • 1
    I'd like to point out that Logging isn't really all that good of an example. It's more of a cross cutting concern that's probably better handled by AOP (IMO) than DI/IoC.
    – rossipedia
    Jul 21, 2012 at 9:12
  • Amusing rant I found - not directly aimed at DI/IoC but pretty much hits the nail on the head anyways - discuss.joelonsoftware.com/default.asp?joel.3.219431.12
    – Ryan
    Mar 10, 2014 at 11:07

2 Answers 2


Does your app need to work? Yes? Then use DI.

Having statics makes your code troublesome to test automatically (since tests often should be run in parallel to decrease turnover time and to help verify concurrency of your code). If you can't automatically test your code, it will be more difficult to make it work properly.

Now, an IoC container is probably overkill. Personally, I've seen them cause more trouble (integration troubles, overhead of configuration) than they solved. But having at least optional DI (that maybe defaults to a static instance even) will help you avoid many problems.

If you have a quicky throw away app that doesn't really need to work completely, then sure; hack away. Otherwise, take the time to do it right.

  • So - in the case of a logging framework you would add that as a dependency to every single class that logs (which could be pretty much everything)
    – Ryan
    Jul 20, 2012 at 19:37
  • 1
    @Ryan: short answer: yes. BTW, I don't think that presenting DI as a precondition to the application working is true; There have been many working, and well-designed, applications before the DI era. Not using DI would certainly lead to an application being un-testable. So I would rephrase that as 'Does your app need to be unit-tested? yes? then use DI'
    – J. Ed
    Jul 20, 2012 at 20:17
  • 1
    @Ryan - it's already a dependency, you're just making it flexible and explicit.
    – Telastyn
    Jul 20, 2012 at 21:47
  • "Does your app need to work" is a step too close to religious edicts for my taste - as eloquently pointed out by sJhonny. If thats what you have to resort to to make your point then isn't the point already lost? + 1 for the rest of the answer though!
    – Ryan
    Jul 21, 2012 at 12:04
> using DI and optionally a IoC framework [is] a step too far

if you

  • don't want to do automated (unit-)testing and if you
  • don't have separate components of the app (i.e. dlls) that should be changed (or recompiled) independently of the main app.
  • The example I gave (using the Globals class with a default NullLogger) still allows you to do both of these things.
    – Ryan
    Jul 21, 2012 at 12:01

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.