Spring.NET - It's Shiny! I Love It!

The boring bit about what Spring.NET does, from their overview page:

Spring.NET provides comprehensive infrastructural support for developing enterprise .NET applications. It allows you to remove incidental complexity when using the base class libraries makes best practices, such as test driven development, easy practices. Spring.NET is created, supported and sustained by SpringSource.

This is how you know that Spring.NET is ready for the enterprise: a whole paragraph which doesn't actually tell you anything. (and for you java weenies out there that are getting ready to go on and on about how its from java: I know)

Truth is, there's a lot to the whole Spring.NET project, a lot more than I'm going to cover here. Basically, its a code framework, or a set of utilities to simplify writing code. Why would a self-professed IT goon be interested in a code framework? Let me show you how I've been using it.

The main point of interest, for now, is the IoC container. I'd like to copy and paste what that's about, but the Spring.NET punts on that, and sends you to a couple of other pages. The short version is that rather than having one class "know" a lot about another class - specifically initialization, in my case - there exists an outside "container" which knows about all the parts, and pulls them together. In a best case scenario, the classes themselves know little about their dependencies.

Here's a pseudo-config:

<spring>
<objects>
<object name="CustomClassThing" type="CustomClass.Thing, CustomClass">
<property name="SomePublicProperty" value="meh">
<property name="SomePrivateProperty" value="heh">
</object>
</objects>
</spring>

Given that, when the code calls (abbreviated):

Thing thing = context.GetObject("CustomClassThing");

It will not only get a "CustomClass.Thing", it will get it with the two properties set to the specified values, even private properties. There's variations for all kinds of objects and values. You can even use another object specified in the same config.

Let's put our IT hats on for a minute, and see what this gives us: configurability, without having to go ask some developer to make a change. All they have to do is expose anything remotely configurable as a property, and you only need to bother them for the inevitable bugs. If you don't think this is a big deal, then you haven't ever tried to get an enterprise development group to make a config change.

As a developer, you can spend a lot less time worrying about how your objects are going to get their configuration details. The calling object doesn't worry about it, the receiving object doesn't worry about it. It's like magic, only it's not.