SharePoint Abstraction

There seems to be a seismic change afoot in the SharePoint development world as those of us working on the ground with SharePoint move forward with the platform. In my mind this is the SharePoint community growing forward from our dark history as we move beyond the pains of dealing with pure SharePoint and begin to view it as just another component of the applications we build. Instead of building into SharePoint we’re building on top of it.

WTF? I’m talking about wrapping domain abstractions around the SharePoint API so developers can work more intuitively with the domain model and for the obvious performance and unit testing benefits. In essence, it’s a return to good up-front design and worshipping the gods of encapsulation.

When I first started out in the real world everyone was building frameworks. In the object-oriented world, design often starts with the problem domain and a class hierarchy is constructed to model or reflect the relevant entities. The framework becomes the programmatic representation of both the problem and solution. You would never force the developers using that API to, for example, deal with a list of Objects that (these were the days before generics) that would have to be cast to a specific type; your list would derive from an existing list class or one of its parent classes and close the gates to a subset of types and strongly-typed operations. Database access and whatnot would be similarly bubble-wrapped with a common, isolated, and tested mechanism to open a database connection, manipulate a specific object, and clean up.

The last few years of dealing with the minutiae of the SharePoint API has led us astray on the back of the SDK and correct and incorrect code samples available online. Instead of taking these snippets at face value—as samples to be adapted to meet our needs, they’ve been viewed as the code to make SharePoint work at its most basic level. WSS 3.0/MOSS 2007 bugs aside, it’s been difficult bridging the gap from managed to unmanaged code for those of us raised in the cuddly worlds of Java and .NET. Simply put, the SharePoint API is large, comes complete with legacy baggage, and doesn’t always do things the way .NET developers expect. Fair enough, it’s a big application (er, platform) with a history of its own and a wealth of functionality… and it’s not .NET! The end result, however, is we’ve been too busy dealing with a steep learning curve to bother with the application of good design practices and hide away things those aspects that are hard to do well.

The first inkling in my mind of a return to abstraction came from reading Eric Shupps’ post on test driven development with SharePoint. I’m neither a TDD user nor am I a fan but after seeing it in action at Jeremy Thake’s Perth User Group presentation last week, I now understand not having to mock the SharePoint API by abstracting countless objects make building unit tests a lot easier. But wait a minute—encapsulating access to SharePoint and refactoring an application to match the problem domain sounds familiar! Oh yeah, that’s because we used to do it all the time!!!

The Microsoft Patterns and Practices gang have been busy putting together the long awaited SharePoint Guidance bits. It’s interesting to note the sample application they’ve built makes welcome use of abstractions based on common design patterns—all of which are clearly documented. Microsoft obviously has a lot of interaction with customers and the community, apart from product knowledge of both SharePoint and .NET, so the SPG will most likely prove to be an invaluable resource as we expand our understanding of SharePoint and real best practices become apparent.

One final note: my previous tech lead (who now works on SharePoint v14) is a beautiful Japanese fellow with no time for big, unwieldy frameworks and sprawling code. I would label him very much a follower of the minimalist style—an approach not invaluable to IT as a whole (I believe we like building complex solutions because the challenge makes us feel good). So where does the argument for abstraction fit with simple, clean design principles? I believe the two go together hand in glove for the simple reason abstraction leads to centralisation and therefore consistency, meeting the minimalist designer’s goal of less code. Instead of every developer handling list access in a different way with ten lines of code wrapped in three using statements, a developer calls a method in one line of code. But this is perhaps another discussion ;-)

Additional Reading

• Chris O'Brien: Simple Data Access Pattern for SharePoint Lists