Custom Data Service Providers


Data Services sits above a Data Service Provider, which is responsible for interacting with the underlying Data Source on behalf of the Data Service.

Data Services ships with some internal providers, and makes it possible for you to create custom providers too.

So the obvious question is...

Do you need a Custom Data Provider?

Creating a Custom Data Service Provider is a fair amount of work, which of course provides big dividends like, allowing people to:

  • Query and manipulate your data via the Data Services Client in:
    • WPF
    • WinForms
    • SilverLight
    • etc
  • Query you data directly via a browser
  • Query and manipulate your data via Javascript and associated frameworks like JQuery
  • Query your data via knowledge worker tools like PowerPivot.
  • etc.etc.etc.

But before you jump into creating a custom provider, see if you fall into one of the following camps, all of which have a much easier solution:

Entity Framework

If you plan on putting a Data Service over the Entity Framework the answer is no you don't need to write a custom provider.

Data Services has an implementation that talks to the Entity Framework in the box.

You simply point your DataService at your strongly typed ObjectContext, and that’s it:

public class NorthwindDataService:

In this example NorthwindEntities is your strongly typed ObjectContext representing the Northwind database.

For a good example of an OData Service built using the Entity Framework check out this post.


If you want to create a Data Service over a LINQ to SQL data source you should take a look at this project on Code Gallery.

It includes sample code you can use to extend your strongly typed DataContext class to implement the IUpdatable interface.

This in conjunction with the Reflection Provider means you can use your LINQ to SQL DataContext just like an Entity Framework ObjectContext:

public class NorthwindDataService:

Reflection Provider

If you have your own class that can represent your Data Source, and it has a number of strongly typed IQueryable properties like this:

public class MyDataSource
public IQueryable<Product> Products { get {…} }
public IQueryable<Categories> Categories { get {…} }

The built-in reflection provider can turn this into a read-only service and infer ResourceSets, Types and Properties automatically.

You can even make this read-write by extending your class to implement IUpdatable:

public class MyDataSource: IUpdatable

In fact this is exactly how the LINQ to SQL example above works.

For a good example of an OData Service created using the reflection provider check out Tip 56.

So when do you actually need a custom provider?

The reflection provider is very useful for some scenarios.

But is has a number of limitations that might disqualify it for your scenario:

  1. It is static, i.e. the shape of the service can’t evolve over time.
  2. It needs CLR classes for each ResourceType, which you might not have.
  3. It needs to find Id or {Type}Id properties to use as keys.
  4. It blindly exposes all public properties of the CLR classes.
  5. It gives you less control over streaming or paging.
  6. You can’t take advantage of advanced features like Open Types, which allows resources to optionally include more Open Properties.
  7. You have less control, for example you can't log requests as easily or modify metadata or rename properties
  8. etc. etc. etc.

If any of these are important it’s time to create a Custom Data Service Provider…

Creating a Data Service Provider Series

This series of posts will grow to cover all of the major DSP interfaces and show case lots of scenarios

Part 1 – Intro
Part 2 – IServiceProvider and DataSources
Part 3 – IDataServiceMetadataProvider 
Part 4 – Minimal Running Service
Part 5 – Query
Part 6 – Query Interactions
Part 7 – Updates
Part 8 - Relationships
Part 9 - Untyped

possible future installments…

Part 10 – ETags
Part 11 – Friendly Feeds
Part 12 – Streaming
Part 13 – Advanced Paging