How do I get an object into a deeply nested method without passing it through every object?

Question

Lets say I have a method which requires a static property and I want to create unit tests, so I wrap it in a wrapper class. Let's call the interface IFoo & concrete class Foo.

Now if my method is called from within an MVC view, how do you get the wrapper instance into that method?

Obviously, I can add an IFoo parameter to my controller constructor, an IFoo property to my view model, and an IFoo parameter to my method, then pass it down the chain; controller, view model, view, extension method. That doesn't seem acceptable me.

So is there a cleaner way to do this?

I assumed a DI Container was the way to go. To be honest, I haven't needed one up until now, and I naively assumed I would just add Ninject, bind concrete types to interfaces, and make the following call within my method.

var dt = kernel.Get<IFoo>();

I assumed this would help me to avoid the entire constructor parameter / property trail mentioned above. Now I knew I'd still need to get the kernel variable from somewhere, but I thought I remembered seeing something about invoking it with thread/session/request scope. I thought I could instantiate the same instance of the kernel regardless of where it was invoked, but when I looked into it I found out that is only for the object instances the kernel is invoking ... not the kernel itself.

So, Is there any way to get an instance of Foo into the method without passing it through a bunch of objects which do nothing but pass it?

Answer 1

Since I don't know your exact use case what I might suggest may or may not be appropriate. There are a couple of ways that I've handled this and it depends on where you are testing. From the extension method point of view, I think you can just have it take a DateTime and manually inject appropriate values in your unit tests for the extension. If it needs to test a value against DateTime.UtcNow, that's a bit different but you can handle it with a nullable DateTime that defaults to DateTime.UtcNow if you don't supply on in a second parameter.

   public static IHtmlString RegularExtension(this HtmlHelper helper, DateTime when)
   {
      ...
   }

   public static IHtmlString ComparisonExtension(this HtmlHelper helper, DateTime when, DateTime? now = null)
   {
       var nowDate = now ?? DateTime.UtcNow; // verified by inspection, tests use specified values
       ...
   }

or, for the latter, if you don't feel comfortable with the null coalescing operator, use two methods. A public one that takes a single parameter and a private one that uses both. Test your private method using reflection, have the public one simply delegate to the private one. You might also consider using a single method where both parameters are required and always build both values into your model.

From the perspective of the controller, if you need to use a consistent value for the current time, you could inject the wrapper into the controller and have the model populated with the "unwrapped" value from the wrapper. That way you can test that the controller properly sets the value on the model without having to tie everything downstream to the wrapper. The key is that all your code uses the injected (and unwrapped) value instead of calling DateTime.UtcNow directly. From the perspective of the tests on those classes, they don't know where the value comes from, just that it's supplied from upstream.

   public FooController(IDateTimeWrapper timeWrapper)
   {
       var model = new FooModel { Now = timeWrapper.Unwrap(), ...  };

       ...

       return View(model);
   }

Answer 2

If your ViewModel or View is created by Ninject as well, you should be able to add IFoo as a constructor dependency and get it injected. If you want to directly access the Kernel and resolve an instance (which is usually not the best idea) you can inject an IResolutionRoot and call Get on it.

Answer 3

First, buy http://manning.com/seemann -- you won't regret it.

In general, the problem of "I'm here in my object tree, give me the X" is addressed in one of the following ways:

• Constructor Injection - any object that needs an X, asks for it at construction time. See Injection Patterns in the Ninject Wiki
• Service Location - everyone can always scream at a central mother figure to get stuff - i.e. keeping a ref to a container in a static and calling it willy nilly - see the ploeh article of the same name
• Abstract Factory - you get injected a Func<T> or an interface IXFactory { X CreateX(); } - see the Ninject.Extensions.Factory wiki
• Method Injection - it gets created somewhere and you pass it around as necessary - see the Dependency Injection in .NET book

You're expecting a bit much of the container to make it magically possible for anyone anywhere to scream, "I want the X", especially in a static class being called from a DTO. Remember, a container doesnt go in and rewrite your IL interceptign calls to new. In can essentially apply a few Decorators, Factories and Proxies as glue when doing unglamorous wiring stuff together work.

The bottom line is that the appropriate way to handle stuff like this is

• Anything that needs DI should (and can) not be static, period
• Short term object instances such as DTOs should not participate in DI (which is not to say one should Compose Object Graphs with confidence even when processing requests - it's just that what you're wiring should be Services, not objects). See Why not use an IoC container to resolve dependencies for entities/business objects?
• Most of the time you're best off making dependencies explicit via Method Injection and Constructor Injection - that way it pushes your requirements to the surface rather than creating an out of band communications rats nest via Service Location

The last point is critical - by surfacing the real dependencies and listening to them, you'll end up figuring out where the Time Service, Scheduler or Formatter (or whatever the higher level abstraction that's missing in your case) should live over time.

I strongly suggest reading Mark Seemann's top answers around here as most of these important questions and topics are addressed in depth across them, without relying on oversimplified explanations as my answer does. Of course the book itself is the best overall use of your time and money though!

EDIT: (Inspired by your comments with @tvonfosson) One key thing a Container can bring to the party (aside from maintaining a single X within a given scope (see Ninject.Extensions.NamedScope wiki) is to be able to skip passing indirect dependencies down a hierarchy of services for no reason - i.e. if your Controller depends on a Service which depends on a Scheduler and the scheduler needs a Clock, the Service doesnt need to be talking about Clocks, just Schedulers.

The key thing with Containers is to make sure you don't go too far and then try to abuse them for code that should just be code.