Question

I’m wanting to create an OData service that returns data from multiple sources. For this reason I cannot use WCF Data Services with any of the out-of-box providers, plus we really want more control over the data model.

I see we have two options if we stick with the MS product stack;

1. Use WCF with WebGet/WebInvoke to mimic an OData api, and perform the query string parsing and translation internally. e.g. For cases where our data is in a Sql database we must translate the $filter clause into a SQL where clause in order to build our query. Note here that we cannot use any kind of ORM here, since our Data model is dynamic and we don’t have any CLR entity classes that could be populated with an ORM.

2. We use WCF Data Services with a Custom provider, this requires us to pass an IQueryable for the resource set, which leaves us with either doing a Select * FROM Table and using Linq to objects, or implementing our own IQueryable provider that supports the expressions required by OData. Will WCF Data Services even accept an IQuerable?

Which would be the easiest to implement? We mostly only want to support the $filter features of the OData spec, $expand and $select can come later.

It seems a shame to abandon WCF Data Services, it would be preferable if it could supply the parsed OData query that you could then translate to a Linq query yourself, rather than expecting your data source to have an IQueryable provider.

Answer 1

You can write your own data context class. The more functionality you need the greater the effort. The WCF Data Services Toolkit may be of some help and I found this OData Roadmap: Exposing Any Data Source as an OData service presentation from MIX to be helpful.

So I say writing a custom IQueryable provider would be both easier and cleaner.