External Value Configuration with IoC

Friday, June 13th, 2008.

One of the things I haven’t like about using IoC containers, AKA dependency injection frameworks, was the string-based configuration model they exposed. In order to set these values, developers had 2 options: either use XML config (usually without the benefit of intellisense or refactoring support), or use code (still quoting property names - again, no intellisense or refactoring support).

In short, there seemed to be a hole in the development model.

Here’s an example from how nServiceBus used to do this:

builder.ConfigureComponent(typeof(HttpTransport), ComponentCallModelEnum.Singleton)
.ConfigureProperty(”DefaultNumberOfWorkerThreads”, 10)
.ConfigureProperty(”DefaultNumberOfSenderThreads”, 10);

The problem was that if a developer got the case of the property wrong, misspelled it in some way, or somebody later refactored/renamed that property, the system would break. It would also be very difficult to figure out why.

Then, a couple of weeks ago, it dawned on me.

This was the same problem we used to have with testing using mock objects - before we had today’s more advanced frameworks. So, the solution must be to use the same techniques. The container should give the developer an object that looks just like their class, but that would intercept all calls. Then, that interceptor could turn those into the config calls shown above. Here’s what the new config model looks like:

HttpTransport transport = builder.ConfigureComponent<HttpTransport>
(ComponentCallModelEnum.Singleton);

transport.DefaultNumberOfSenderThreads = 10;
transport.DefaultNumberOfWorkerThreads = 10;

Granted, you’re not going to have tons of code like this. However, for all those parameters which are factory-configured and that customers/integrators shouldn’t tinker with, it makes a difference. The biggest difference is during that time of development where you’ve gotten into preliminary integration tests but the systems components are still being “polished”.

Aside: On the current project that has adopted this model, we’ve probably saved (conservatively) about 3 months of effort with this tiny (?) thing, and this isn’t a huge project. If that’s more than you would’ve thought, well, I was surprised myself. First, understand that in the old config model, everything still compiles and unit tests pass, even though its broken.

Just consider what happens in the lab when this occurs. You have N testers that can’t test the new version, waiting. You have the person who installed the version, trying to figure out what’s wrong. They then call in one of the developers where most of the new development occurred since the previous version. They fiddle around with it, looking at exception traces and whatnot. In the best case, we’re talking about 2 hours from noticing its broken until a new version comes out fixed. Multiply that by N+3 people. Then multiply by the number of versions you do integration tests on in the lab.

Caveat: In the current version, properties must be virtual in order for this to work.

For those of you who want just this feature without nServiceBus, I’ve put up all the binaries here. For the source, you’ll need to go to here.

Let me know what you think - especially if you can take the implementation to the point where it won’t need virtual properties to work

If you liked this article, you might also like articles in these categories:

If you've got a minute, you might enjoy taking a look at some of my best articles.
I've gone through the hundreds of articles I've written over the past 4 years and put together a list of the best ones as ranked by my 2000+ readers.
You won't be disappointed.

If you'd like to get new articles sent to you when they're published, it's easy and free.
Subscribe right here.

Something on your mind? Got a question? I'd be thrilled to hear it.
Leave a comment below or email me, whatever works for you.

12 Comments

Jeremy Gray Says:
June 13th, 2008 at 12:08 pm
Regarding the need for the properties to be virtual, would a syntax like the following not solve that problem quite easily?

(I don’t know how well the characters will make it through your comment system, but hopefully the point will come across.)

builder.ConfigureComponent(ComponentCallModelEnum.Singleton)
.Configure(o => o.DefaultNumberOfSenderThreads = 10)
.Configure(o => o.DefaultNumberOfWorkerThreads = 10);

or some version that merges both property assignments into one lambda passed into a single .Configure call? These delegates would then be executed directly against the instantiated component, and could even be typed as Expression instead of Func if you wanted to be able to generate their text representation at runtime to provide diagnostic output.

Jeremy Gray Says:
June 13th, 2008 at 12:10 pm
re: “instead of Func” I mistyped that while meaning “instead of Action”.

Steve Says:
June 13th, 2008 at 8:44 pm
Might want to take a look at autofac. It is a very full featured IoC container written from the ground up in C# 3.0, no strings or ugly xml necessary.

Nicholas Blumhardt Says:
June 14th, 2008 at 12:52 am
G’day Udi!

How about considering configuration based on a function? E.g. along the lines of:

builder
.ConfigureComponent(ComponentCallModelEnum.Singleton)
.OnActivating(instance => {
instance.DefaultNumberOfSendThreads = 10;
instance.DefaultNumberOfWorkerThreads = 20;
});

?

Cheers,

Nick

Nicholas Blumhardt Says:
June 14th, 2008 at 12:56 am
BTW, that one will work when the properties aren’t virtual.

If you really need to get at that configuration information as _data_, you could do the same thing in .NET 3.5 by accepting an Expression rather than an Action as the parameter to OnActivating() - with some minor restrictions.

Cheers

Jeremy D. Miller Says:
June 15th, 2008 at 1:58 am
Using Expressions in .Net 3.5 could potentially shut that little source of errors down — and that might just happen soon with one of the IoC tools. All you need to do is strip out the property name and value both from the expression passed in.

I think you’re exaggerating the problem though. Any level of automated testing should find those errors in an easy to troubleshoot manner. StructureMap would blow up if any argument was missing and tell you the exact constructor argument that was missing. If your IoC configuration is in any way complex, put some environment tests into your build procedures that check on all the configured instances.

udidahan Says:
June 15th, 2008 at 3:48 pm
Jeremy Gray,

The difficulty is in knowing what the expression (or function) does so that I can use it to configure the underlying component, so I’m afraid that what you showed would run into the same problems.

udidahan Says:
June 15th, 2008 at 3:51 pm
Nick,

Just like in my reply to Jeremy Gray, I still need to generate an instance of the class which allows me to intercept calls to its properties for that to work.

udidahan Says:
June 15th, 2008 at 3:53 pm
Jeremy Miller,

Re, “All you need to do is strip out the property name and value both from the expression passed in.”

How do I do that?

Mark Hildreth Says:
June 17th, 2008 at 4:26 am
> Just like in my reply to Jeremy Gray, I still need to generate an instance of the class which allows me to intercept calls to its properties for that to work.

Udi,

I’m not sure I understand the problem with their solutions. You shouldn’t need to intercept anything. The lambda function will simply be an Action which you can store either alongside (or using whatever Spring’s equivalent is to a Windsor’s “Facility”). Then, when you create an instance, invoke all those Action objects on the newly built object.

Is there a specific problem with the need to use the container to set the properties rather than invoke them manually after the container builds the instance? If there is, I’m not sure you could get away with using Expressions without some funky hack, since you would probably want to use the setter, but IIRC Expressions do not allow for using the assignment operator.

Dan Ports Says:
July 11th, 2008 at 11:57 am
I agree with Jeremy Miller that you exaggerate the problem. Even very minimal automated integration tests should pick up issues with configuration values being added, renamed, or deleted, so refactoring support, while nice, does not seem that crucial to me. Is there something we are missing?

udidahan Says:
July 12th, 2008 at 7:30 am
Dan (and Jeremy),

Consider a system that has many processes installed in various configurations on many machines.

It’s quite a bit more difficult to do automated integration tests in this environment.

External Value Configuration with IoC

12 Comments

Your comment...