I see some pieces of the same error-prone code recur far too often in SharePoint. Probably most pervasive is the one to allow and not allow unsafe updates. In this post, I’ll provide a proper solution for this matter.
There’s one specific error that keeps coming back when I create new SharePoint solutions that require multiple assemblies next to the farm/sandboxed solution.
Every once in a while you’ll have a situation in which you temporarily have to use different (shared) settings and reset them if all work is done. An example of this is often seen in SharePoint, for instance disabling events when updating items in event receivers, or allowing unsafe updates. A workaround that I have seen a lot is that developers add a TRY/CATCH/FINAL block for each method they want to reset some objects. In this post, I’ll talk about an alternative way of achieving this behavior by the implementation if the IDisposable interface.
At some point, any developer will have to write some code that must be executed at regular intervals. In SharePoint for instance, timerjobs were (!) very easy to create. In .NET, you could choose between scheduled tasks and windows services. While I was doing research on the ideal replacement for timerjobs in the new SharePoint app model, I came across Quartz.NET. In this post, I will show you which code you need to create timerjobs.
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).