public static Func GetConfigValue = s => ConfigurationManager.AppSettings[s];

I see what you mean. I was focusing on the consumer of the Config factory. Which is NOT using dependency injection. But, yea the sample implementation is using DI. And that’s your point.

What is confusing is that this pattern is really about the resolver. Only the implementation is using DI. Some test implementation may create a IDbCommand that isn’t using a connection. You could easily strip this pattern of DI. You could also do all this DI stuff even without the resolver.

So I would still argue that this article is about a locator/resolver and not DI per say. But since you’re doing it specifically as a means to later do DI it’s related. Got ya.

>> But I have never needed that either, so it is a somewhat constructed argument/problem.

Well, you don’t “need” it. But if you do this, you open up your application for new design possibilities that could change your overall architecture.

But my experience has been that legacy frameworks haven’t considered IoC in the API design which sometimes makes it difficult to use.

However, if you have frameworks that will allow you to utilize this concept through out, it can be very powerful. I can show you some examples later.

Of course, this isn’t as useful on simple applications where you may over engineer your infrastructure code.

>> use the right tools for the right task

!

That is simply not correct.

The definition of Service location is when a component resolves it’s own dependencies (through the help of the locator).
eg. if the SqlCommand class would ask for it’s own dependencies.

This is not the case here, the SqlCommand class can only by configured through dependency injection.

So injecting a connection from the outside into the command object _is_ dependency injection, and that is exactly what is happening inside the GetCommand method.

The config method “GetCommand” ofcourse uses service location to resolve the objects that will be injected into the subject of the configuration (eg. the command object)

This is exactly how it is implemented in DI frameworks also, the DI framework first needs to resolve the dependencies, and then inject them into the subject.

Regarding one config per app domain:
This is true, but I have yet to see a real world case where you need to be able to have multiple implementations of the same configuration in the same application.
Maybe there is some special case where it is needed, but by all means, use the right tools for the right task.

I’ve used the same argument when I built NAspect, that we support different AOP configurations in the same app domain.
But I have never needed that either, so it is a somewhat constructed argument/problem.

For tests I would instantiate a mock or fake Config object in the context where it is needed.

In your sample DefaultConfig.GetCommand doesn’t use DI. You could use it there, but you’re currently using a service locator there as well.

I’m not saying that the pattern is wrong or that it’s worse than common DI frameworks.

In fact, this exact pattern is very common in dynamic languages for testing purposed. Every method is overridable so you have a default that is then overridden during tests.

I’m just saying, you don’t have anything in there that is doing Dependency Injection. So, the term is misplaced to describe the pattern. It’s IoC but not (necessarily) DI.

My issue with this pattern is that the application architecture is designed around a default implementation. That could potentially lead the design process to leak across layers.

But, then I have an issue with DI frameworks and global dependency configuration in general but that’s a different story.

You can’t have two different instances of Config in the same app domain for example. That’s makes all your consumers single purpose. I would have Config be a contextualized configuration object that is passed through injection to consumers.

Yes I’m aware of Autofac, but it actually brings me very little extra compared to the lines of code above.

It does bring some extra object activation features, eg if some object should be singleton or if it should be unique for an entire object graph.

But except for that, I can do pretty much everything with the code above w/o the need for an external framework.

And as the title implies, it is the “simplest form” not the “best” or “most flexible”.

For the sake of the argument, you do not need a hard dependency on a single DI framework, you can build your code to use the common service locator

http://www.codeplex.com/CommonServiceLocator

which is a cooperation between MS and the DI community (initiative taken by Ayende).

Also there are plenty of frameworks that doesnt require xml configuration.. for example autofac.. you can even use Modules spread across assemblies if you want

Daniel Cazzulino created Funq http://www.clariusconsulting.net/blogs/kzu/archive/2009/01/30/116274.aspx

Most of them lets you do non xml/magic string resolving

Thank you for submitting this cool story – Trackback from DotNetShoutout…

Personally I’m not too keen on this as it involves writing an abstracting layer (static Config class) and this means more code. Is the issue rather that the IoC container of your choice is a real pain to easily configure for writing unit tests? Maybe consider one that can be easily configured in code like Bloom on codeplex (note: I wrote it) or Autofac.