Last year about this time I blogged about using Breeze with SharePoint… you can go back and read those three posts that explain the benefits to using Breeze with SharePoint. What does Breeze do for you, the SharePoint developer?
When working with the REST API in SharePoint you have to write a bunch of plumbing code… this is very much like writing the connection objects & T-SQL strings to interact with data stored in SQL Server if you were doing things on the server. On the server we now have technologies like LINQ for simplified queries you write in code & Entity Framework that abstracts the database to code and adds a ton of features. Breeze is basically Entity Framework in the client. It allows you to write your queries without dealing with the REST plumbing code and also adds things like client-side caching & data validation… just like Entity Framework.
Because SharePoint’s REST API has a few nuances, we had to create what’s called a data service adapter to get Breeze to work with SharePoint. At the time we released it last year, it only supported SharePoint 2013 (either on-premises or SharePoint Online) and over time we found a few bugs. I’ve had a bunch of feedback form folks for fixes & feature updates and I’m thrilled to say that we’ve got some great news!
You can view all the updates on the changelog here.
Yes, now you can use the same Breeze SharePoint data service adapter for the SharePoint 2013 REST API (either on-premises or in SharePoint Online in Office 365) or with SharePoint 2010! As we show in the README, the code you use to configure Breeze to use the SharePoint 2013 data service adapter is pretty simple:
breeze.config .initializeAdapterInstance('dataService', 'SharePointOData', true);
When using SharePoint 2010, just specify the new data service adapter for 2010!
breeze.config .initializeAdapterInstance('dataService', 'SharePointOData2010', true);
Notice the version number on the end. Ideally I’d like to have the version number in both, but if I did that I’d current deployments. Plus, the 2010 version is really only there for backwards compatible reasons… no one is going to use the 2010 style
/_vti_bin/listdata.svc endpoint if they are in SharePoint 2013 or beyond.
Interested? The NuGet packages have been updated so you can grab them today!
- NuGet: Breeze Labs - SharePoint 2013 DataService Adapter - yes, this works with 2010… we just left the name of the package the same.
- NuGet: Breeze Labs - Breeze + Angular for SharePoint 2013 - yes, this works with 2010… we just left the name of the package the same.
My bad… that’s all I can say. I made a bad assumption when we originally wrote the data service adapter. When working with objects in the REST API, you have to specify the types. In SharePoint 2013 the type is in the format
SP.Data.[ListName]ListItem (in SharePoint 2010 it’s
Microsoft.SharePoint.DataService.[ListName]Item). The original one was adding & removing an ’s’ to the list name so you could name the entity in your metadata in the singular form.
For instance if you had a list named Customers, your entity would be named Customer in Breeze and all would work well. However what if you had a list named Customer? Well that would break… and that’s bad form… I shouldn’t have written an opinionated data service adapter.
So that’s been fixed… no more adding or removing an ’s’. Now whatever your list name is, you should use the same name for your entity.
So what’s next for the data service adapter? You tell me! I’m looking at two big possible updates and I’m not sure which one we’ll do first. One is adding support for cross domain calls (you don’t need this if you are using Office 365 & you are authenticating using OAuth tokens because in that case you can leverage the new support for CORS… but CORS isn’t on-premises).
The other update is to add support for using the batching support in Office 365’s SharePoint REST API. I’m more partial to this one, but both are important.
What do you think… which one? What about other stuff? Sound off in the comments!!!