Question

I have the need to use Spring .Net in a project and am exploring configuration options. All I can find about config for Spring .Net is config file stuff. Does Spring support configuration in code? I have used Castle and Ninject, and both seem to offer this natively. I have found projects that claim to add support, but I dont want some knock off project that will die in 6 months. I have found references in blogs that seem to indicate Spring supports this but I cant find any documentation!!

Part 2 of this might be would you recommend Spring .Net over Windsor knowing it cant support fluent configuration? I know both are great IoC containers, but I have worked on projects that have massive config files for Spring configuration and I hate it.

Answer 1

No, the current version (1.3) of Spring.NET only supports XML configuration. There has been talk about supporting Code as Configuration in future versions, but this has not yet materialized.

In my opinion, Castle Windsor is far superior to Spring.NET. I can’t think of a single feature of Spring.NET that Castle Windsor doesn’t have. On the other hand, Castle Windsor has the following features that are not available in Spring.NET:

• Code as Configuration
• Convention-based configuration
• More lifetimes
• Custom lifetimes
• Object graph decommissioning
• Explicit mapping of interfaces/base classes to concrete types
• Type-based resolution
• Modular configuration (Installers)
• Built-in support for Decorators
• Typed Factories

There are probably other features I forgot about…

---

It appears I was a bit too quick on the trigger here, although to my defense, the Spring.NET documentation also states that there’s only XML configuration in the current version.

However, it turns out that if for certain contexts, a very primitive API is available that enables you to configure a context without XML. Here’s an example:

var context = new GenericApplicationContext();
context.RegisterObjectDefinition("EggYolk", 
    new RootObjectDefinition(typeof(EggYolk)));
context.RegisterObjectDefinition("OliveOil",
    new RootObjectDefinition(typeof(OliveOil)));
context.RegisterObjectDefinition("Mayonnaise", 
    new RootObjectDefinition(typeof(Mayonnaise), 
        AutoWiringMode.AutoDetect));

Notice how this API very closely mirrors the XML configuration schema. Thus, you don’t get any fluent API from the IObjectDefinitionRegistry interface, but at least there’s an API which is decoupled from XML. Building a fluent API on top of this is at least theoretically possible.