Repository pattern in SharePoint

A few months ago, I had an assignment for a multinational beverage company to implement a publication system for their products across Europe. Along with a few other consultants and managers from another unit in my company, they had decided to go for a SharePoint solution as this seemed to meet all business requirements: centralized master data management with the ability to generate XML – and Word (or other human friendly) documents. I got on the project a few months later only to discover that the suggested approach could never work: the entire data model (entirely relational and normalized) was made with many SharePoint lists and the data was retrieved with JSOM. With a limited budget and a tight deadline, the best thing to do was to make a proper design with a solid architecture and minimal amount of code and complexity. The best alternative here was to build a custom SharePoint solution with a custom ORM layer. I considered LINQ 2 SharePoint but in this project where nothing was certain and everything changed rapidly, I quickly decided that a custom ORM layer was the most suitable. If I had the choice to start from scratch, I definitively would have chosen to go for the combination EF + BCS. As this MSDN article explains, the repository pattern is pretty much the way to go when it comes to building a generic, high quality and lightweight data access layer. This also counts for SharePoint solutions, as Chris O’Brien confirms in an old article. Although many articles cover this topic, I never was quite satisfied with the technical solution that was provided.

In what follows is a very simple yet powerful way of creating a generic data access layer for SharePoint (both CSOM and SSOM).