Unity/Spring or System.Configuration for configuration?

Question

If you are already using Unity as a part of your project, is there any sense in bothering with writing traditional configuration classes?

Doing so seems like it's extra work, but the positives would be more domain specific XML tag names and more concise XML. But then the question becomes when you draw the line between the two and consistency as well.

In the past, when using Spring.NET for IoC, I've used a mix of the two, but I'm wondering if doing so is just reducing the level of consistency in configuration. Certainly, if you are not already using the libraries for IoC/DI, it seems like overkill to use them simply for runtime configuration purposes, but if you are, what approach would you take?

Answer 1

Many developers follow the YAGNI (You aint gonna need it) approach and therefore would not use xml config files as they are seen as overly complicating a simple issue.

I prefer to follow the CMA (cover my a**) approach and put things into xml config files to allow the flexibility of swapping dll's in and out of the application based on customer's requirements / management meltdowns!

One other mechanism I have seen used is a directory searcher which scans a specified directory for dll's and then uses reflection to find a specific interface implementation, this interface usually has a simple method like RegisterServices or Initialize. There is an example of this within the WPF & Silverlight composite application on codeplex, the interface to look for is IModule.

Either way you go I do feel that using DI / IoC is the best approach to ensure you're app is modular and testable. Yes the configuration of it does take a little extra setup work but the 1st time you get a manager saying "I've talked to this partner and they're now going to provide this service for us, make it work" and all you have to do is write some code which implements an interface and then change a dll in a config file, you'll realize the flexibility it gives you.

Answer 2

IMO, you should not use configuration classes but in configuration specific asp.net or dot.net tasks - like compression or configuring http modules, because they are not portable. They require extra work and - overall - are not testable.

More, if you will need to port features to other platforms like silverlight you have to think how to port these configuration classes and how to fit them in different architectures.

Answer 3

It depends. Of course. :-)

What is the purpose of your configuration file, and more importantly, who is the intended audience? Who will be reading or editing the configuration file later?

If the main purpose is to wire up the application, and it's aimed at developers, and your types are reasonably well named, then you can get away with just using the DI container configuration. The danger there is that you've got a lot of extraneous detail that isn't really germaine to "configuring" the application per-se. If you were going to change, for example, a connection string, you really want that in one place, clearly labelled as a connection string.

That's why I ask what the audience and purpose is. Having that more specifically labelled, concise XML tags can make finding, and editing, the right spots for an administrator easier, quicker, and less error prone.

Having said that, doing anything other than simple name/value pairs with System.Configuration is a giant pain in the tuchus. The .NET configuration classes are buggy, seriously underdocumented, and full of strange, unexpected behavior.

I would suggest starting with the container configuration just to get going, and then take the time to explicitly design your configuration schema, concentrating on your use cases and ease of editing.

I don't know Spring so I can't say anything about how it works there. With Unity it's pretty easy to mix and match. You can use the API AND configuration files, so put the stuff your application needs to operate into API calls, and the user-tweakable stuff into the config file. That and dividing up into separate container definitions and even separate config files gives you the ability to segregate the internal wiring from the stuff that admins should, or would need to, touch.

Also, as a last resort the Unity config schema is itself extensible, so you could actually add tags to the Unity config section. But that requires doing work with System.Configuration and fitting it into the Unity config framework, so that's even more work.

So, TL;DR: There's no one good answer here. The general DI config schema has the advantage of being general, and already written. It has the disadvantage that it's not necessarily obvious what needs to be tweaked by an admin, and what is internal wiring details that would break things badly. Custom configuration sections are potentially a lot of work to write, but if done well will provide clear and obvious points for admins to edit without breaking the entire edifice in a non-obvious way.