Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
+1 good question, since it is much easier to ask for benefits or "when to use" of di/ioc. –  k3b Jul 21 '12 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 '12 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 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.

share|improve this answer
    
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 '12 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' –  sJhonny Jul 20 '12 at 20:17
1  
@Ryan - it's already a dependency, you're just making it flexible and explicit. –  Telastyn Jul 20 '12 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 '12 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.
share|improve this answer
    
The example I gave (using the Globals class with a default NullLogger) still allows you to do both of these things. –  Ryan Jul 21 '12 at 12:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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