Spring.Net and SharePoint

I really like test-driven development (TDD). I like the architecture that is forced upon you, and I definately like the quality output from the team. TDD simply works great, especially in combination with a continuous integration environment such as CruiseControl.Net or Microsoft Team Foundation Server.

So, of course I like to use tools or frameworks that enhance the TDD aspects of my projects. Or, to put it this way, I like tools and frameworks that enhance my projects, period. And Spring.Net... well, it really enhances my projects!

And, as an added bonus, you don't have to be too envious of those Java geeks talking about how great Spring is anymore. Great eh?

Spring.Net gives me access to:
* Inversion of Control (IoC) (http://en.wikipedia.org/wiki/Inversion_of_control)
* Aspect-Oriented Programming (http://en.wikipedia.org/wiki/Aspect-oriented_programming)

So, of course I'd like to use Spring.Net in my SharePoint projects. At the start, I was not so sure whether the technologies would work nicely together. But, let me assure you, after running it in two MOSS 2007 projects, I have still to find any problems with the combination.

Inversion of Control
By using Spring.Net I get a simple dependency injection running. It does create some hassle for the developer since dependencies between objects are now specified separately from the class file. But - we get the perfect TDD architecture running. Creating unit tests with mocking logic is now very simple. My junior developers also learn to code in a more structured fashion - with more "black box" design.

Do I apply dependency injection on all my objects then? No. So far I've only done this for Business and Data layers - that is, everything but the UI layer.

Why? For two reasons - it would complicate things for SharePoint, and well, I generally do not develop unit tests for user components anyhow since testing graphical interfaces is quite complex and expensive. Note that I make sure to keep logic in the UI layer at a bare minimum of course.

Aspect-oriented programming
Now, here's where the real fun begins. You do not see the value with dependency injection? Fine, you'll do well enough without it, especially with a good mocking framework.

But, using Spring.Net's dependency injection is required to get aspects working. Imagine the possible potential of developing your own aspects! So, have I created my own aspects? No. Quite frankly, so far I've only come around to using the built-in aspects available in Spring.Net. But boy, are they worth it.

One in particular stand out - the caching aspect. It uses the ASP.Net caching to work it's magic and since we're building a portal using SharePoint, it's a perfect fit. And lets face it - a portal will require a lot of caching to get the performance of a user-friendly site.

I've used several caching frameworks in my career (for example Microsoft Enterprise Library) and Spring.Net easily beats any other frameworks I've tested. Put simply, the caching aspect has saved weeks of work in my latest projects, and not once has it not worked as expected.

Time for an example:
In your data layer SettingsDac is responsible for retrieving and storing settings in your application. Settings are stored in a SharePoint list, but getting them from the list each time will impact on performance, so you want some caching.

This is the code, using Spring.Net and the caching aspect (a bit simplified):

[CacheResult(CACHENAME, "'Setting.Key=' + #key")]
public SettingsBE GetSetting(string key)
{
SPList list = GetSecurityElevatedList(LISTNAME);
// TODO: Validate list.
SPQuery query = new SPQuery();
query.Query = string.Format(QUERY_KEY, key);
SPListItemCollection listItemCollection = list.GetItems(query);
// TODO: Validate that we have exactly one result.
return CreateSetting(listItemCollection[0]);
}

As you can see, the only code the developer needs to get caching is the attribute CacheResult, the rest is done automatically (with the help of some configuration).

So, AOP might be complex sure, and all developers won't understand how it works, but frankly... When it's as simple as in the example above to use... do they have to understand it? As long as they get directives to, for example, only use it in DAC classes.


If you haven't tried out Spring.Net yet - do it now. You'll never regret it. :-)