Why is xml so prominently featured in IOC containers?

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 othe开发者_如何学Pythonrwise very cool, advanced technologies are relying on xml.

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.

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.

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.

In IOC and many other "configurable" technologies.

The thing is ( was ) that XML emerged as standard for document interoperability.

So instead of having everyone creating it's own format, everyone adopted the "new" format.

It was good for a while, but eventually it became annoying, as you point out.

About specifying it in code, well, the thing is, sometimes, the code have to be recompiled for the changes to take effect while the XML being text/plain allows modification without recompilation.

New formats are emerging, but none has made such impact as XML did.

IoC containers should be considered as render engines to deploy/configure applications non-programmatically, rather than programmatic frameworks to facilitate the IoC design pattern.

Therefore, XML is used mainly for two reasons:

1. to explicitly visualize the semantics of the constructed applications, rather than verbalize the constructing procedures.
2. to have the configuration code interchangeable among external heterogeneous applications that provide value-added features (such as configuration display, verification, transformation, and edit). I.e. the intention is to open up the containers through data integration rather than API integration.

Fluent API lacks the schema verification of data model and also very inflexible to be used for the intended data integration, hence, not even comparable to XML configuration.

See XML in IoC containers: A Hell or a Realm for further discussion.

Because it's what everybody else is doing in the .net space. It started with the web.config and people started extending that. but I do believe most of those technologies support both configuring by XML and by code. The main difference would be the ease with which a non-coder like a system administrator responsible for deploying a application to change the configuration. If that's needed then XML is still a viable option in my opinion. I do believe the .net world is starting to trend to convention over configuration instead of putting everything in XML config files.

XML schema can be validated making it possible to be "strongly typed". One of the main reasons it is so popular is it is pretty easy to understand and there are so many parser frameworks in pretty much any programming language you want. There is nothing stopping you from using a flat file (such as fixed width or CSV), INI files, JSON files, or even custom binary formats if you want.

XML is also popular becasue most of the larger frameworks have direct serialization methods to convert from XML content to a complex object structure native to the enviornment.

Things have since changed in the Java world with the possibilities offered by the use of annotations but you should read I don't get Spring by Bob Lee, the author of Google Guice.

EDIT: As mentioned in a comment, it's unfair to cite the previous post without mentioning I was too hard on Spring.... That's now fixed. Thanks for reminding me of this.

You can have code completion for xml. For instance, there is an eclipse plugin for Spring configuration files that among other things shows the javadoc of the property being set as tooltip, offers auto-completion for the names of classes in your classpath, marks any bean references that could not be resolved within the current file etc. pp.

Configuration files are actually a form of DSL - tailored to express application configuration. This tailoring allows to express certain things more easily. For instance, how would you ensure proper application shutdown (a component must be shut down before its depedencies) when you initialize components in Java? How would you configure an interceptor around your business service layer?

As for why they are done in XML, I guess a DSL was required, and XML had the benefit of an existing rudimentary toolchain (editors, validators, parsers, ...).

Nobody mentioned that XML can be result of an XSLT transformation, and custom DSLs can be created in such a way on top of the plain IoC configuration. It's a very powerful approach.