Why is xml so prominently featured in IOC containers?

Question

I'm trying to get into IOC containers, and I notice a large number of them are using xml configuration. Can anyone enlighten me as to why many new technologies are moving towards xml config/programming models (WCF, WPF, Spring.NET, Unity, Windsor)? It seems that xml is a poor choice for specifying complex settings and it would be better to do it in code where things are typesafe and we have intellisense. I know that some may find this argumentative, but I really am curious as to why these otherwise very cool, advanced technologies are relying on xml.

Answer 1

I moved my Unity configuration into XML just for one reason - I can change configuration without re-compilation of my code. This is very useful in some cases.

Answer 2

It's like wondering why hammer has a steel head when you'd rather glue things together.

Assembling application at run-time from declarative configuration files is the goal, DI itself is just means of achieving it.

If you can code configuration in, why use IoC framework at all? Take somewhat more tightly-coupled design and save yourself a lot of pain.

Answer 3

In general, I like the fluent interfaces for IoC, as mxmissile suggested (I use Unity).

While this does mean that only a developer can change things (as Matthew Whited pointed out), how often do you want a non-developer to be able to replace one class with another in your application? In those cases, you can prepare a simple configuration dialog (backed by whatever data store you want) and have the results from that control the fluent configuration. This avoids fragility and security concerns. Because if an end-user screws up your config file, you are likely to be blamed when the application crashes.

The main use case I have for changing configurations is for unit testing. In that case I can either manually inject fakes into my class under test (which is what I usually do) or re-do the fluent configuration.