Why and how?

Wouldn’t it be great to have the ability to retrieve data from SharePoint in the same manner you are familiar with from Entity Framework? 🧐 At least that’s what I thought when I began working with SharePoint, having worked with EF for several years.

I thought there must be a way to retrieve data from SharePoint without having to work with dictionaries and create custom parsers to convert it into class models.

And then it hit me! Why not attempt to replicate the approach used by Entity Framework? EF is user-friendly, easily extensible, and does not require numerous custom parsers.

So that’s why I’ve started a Proof of Concept (POC), where I aim to implement the functionality from EF. I have made my repository public, so everyone is welcome to provide input and contribute ideas.

See GitHub repository

How does it work?

To make it work, you need to add a number of custom attributes to its class models.

• SPList
• SPField

Example class

[SPList(listGuid: "128b4e17-691a-4e28-9934-7bd399ba907a", listTitle: "EmployeeTasks")]
internal class EmployeeTaskModel {
  [SPField(internalName: "ID")]
  public string? Id { get; set; }
  [SPField(internalName: "Title")]
  public string? Title { get; set; }
  [SPField(internalName: "EmployeeTask_Done")]
  public bool? Done { get; set; }
  [SPField(internalName: "EmployeeTask_Employeer")]
  public FieldLookupValue? Employeer { get; set; }
} 

SPList - It should be thought of as similar to the Table-attribute (e.g [Table(“StudentMaster”)]) from EF, but it accepts both a GUID and a title. First, the code will attempt to find the list using the GUID, and if not found, it will try to find it using the title.

SPField - It should be regarded as the Column-attribute from EF, and similarly, it accepts the internal name of the list field. This will be expanded significantly in the future. One of the ideas I have is to allow you to define whether it should be converted to an enum as well.

How to use it

To use this, it doesn’t take much effort as it is neatly packed away. Therefore, only a few methods are exposed/displayed. However, it must be noted that it is still only a POC, and therefore, not everything is thoroughly tested or handled for errors very gracefully.

A prerequisite for using this is to have the PnP Core SDK installed, as all extensions, etc., are built on PnP’s web context and models.

Get list items

Normally, data would need to be extracted in the following way.

var list = context.Web.Lists.GetById(new Guid(...), p => p.Title, p => p.Items, p => p.Fields);
var listItems = list.Items.AsRequested();

Now, it is neatly packed away, so data is extracted in this manner. Unlike the previous method, this one parses the data to the specified class model.

IEnumerable<EmployeeTaskModel> items = context.Web.GetItems<EmployeeTaskModel>(p => ...);

Update a list item

Updating a list item can be done incredibly easily and quickly. Just take a look at this method:

internal EmployeeTaskModel UpdateEmployeeTask(EmployeeTaskModel employeeTask){
  EmployeeTaskModel updatedTask = context.Web.UpdateItem(employeeTask);
  return updatedTask;
} 

To summarize

This POC was created to determine if it was feasible to extract data from SharePoint in an easy and efficient manner, similar to what we are accustomed to with EF.

I will continue working on this POC with the hope that one day it will evolve beyond just a proof of concept. Perhaps, in the future, it could become a part of the PnP Core SDK? 🤩

Jeppe Spanggaard

A passionate software developer. I love to build software that makes a difference!