Spring Season

Codes can be downloaded here

Yesterday, I got the chance to tinker with another wiring framework, the grand daddy of them all – Spring.NET - which is actually the first wiring framework I came to know about. This is already my third post with regard to wiring framework so you can expect some references to the castle and unity posts along the way. Like the last two, I’d like to share the opinions from the point of view of someone who just wants a quick wiring solution.

First, you need to download the framework here. Spring is an application framework encompassing other concerns which include but not limited to data access, logging, and testing. The documentation is pretty impressive, complete with samples. It even explains the concepts that drives the creation of framework. Best of all, it has a PDF format which I prefer because of the bookmark feature.

Since we only want wiring framework, the Spring.Core dll would suffice. This is located in the <spring framework installation folder>\bin\net\2.0\release. Make a reference to it together with the abstraction and the concrete assemblies.

Like any other frameworks that utilize the .NET configuration feature, Spring requires configuration entries. This part is well documented so nube shouldn’t have any problem. As you can see in the illustration below, Spring uses the term “context” for what we usually refer as “container” This may be because the context object has more functions other than resolving objects but I haven’t explored this yet. Among the 3, I find Spring entries to be the most verbose. First, you need a separate handler for the object (type in Unity, component in Castle). Then, the context should have a reference to the section which contains the objects it can resolve. In Unity, the objects are simply nested within the container and Castle is similar but doesn’t give you the option to specify which container the objects belong. One thing I like though is the absence of the interface declaration in the objects. In the declaration for the object “searcher” we don’t have to specify ISearcher.  Doing so would have been redundant since you will specify it in the codes anywise.

Nothing new with the code part. You instantiate the context, which in our case is the default. The resolution however, could have benefitted from generics. Among the 3 framework, this is the only one that uses casting.

Voila!

I’m sure there are still so many features in Spring that need to be explored. One feature which piques my curiosity is its tight integration with NHibernate. For the time being, I think I should be good with Castle.