Antix Software

It is so easy to get drawn in to the beauty that is IQueryable<> as a data layer API.

It offers irresistible promise of future flexibility and ease of maintenance. You see old systems which are inflexible and require major rework to add new functionality, and you do not want to leave a system in place which is like this.

Your development is Agile - not fully spec'd

Your team is chomping at the bit

... and IQueryable beckons you in.

Fact is IQueryable is a lofty goal.

Very few IQueryProviders live up to the IQueryable ideals and do not offer anywhere near the amount of coverage that you will require to let your api loose on a team of developers ... and, as soon as you adopt a provider, be sure you are writing bespoke code for that provider in your client - early on - there will be no switching.

Take some examples.

I create a data API which exposes IQueryable for a set of X

interface IDataContext{

    IQueryable<X> Xs { get; }
}

I create an implementation, and pass it on to my team, they do the following

var xAndYs = dataContext.Xs.Include(x => x.Ys);

Oops, Include => EntityFramework.dll!System.Data.Entity.DbExtensions.Include

the addition of the is code in your client application ties it to EF, you cannot swap out the provider without rework.

Then what about this...

var x = dataContext.Xs.First(i => i.Id == 1);

Oops, First(lambda) unsupported in Azure table storage, no moving to the cloud here without rework - one of many, many examples

Say I am not going to switch providers - ever

So why would you care, I want to use EF and I don't want to swap out my provider or go to the cloud.

Your developers will still be able to write (not that they would) massively inefficient queries against the data source.

Lazy loading issues may be circumvented by the ToArray (ToList) fix all.

Enormous joins and parent-child row combinatorial explosion bringing you app and infrastructure to a grinding halt.

So what is the answer then

Well its an old one, a repository pattern API, where you expose exactly what your application requires and no more. You write your API using a simple interface accepting arguments required specifically for the job. You then make your implementation using what ever you like, EF, Azure Storage Client, nHibernate or what ever, but you hide it behind this simple api.

interface IDataContext{

    IEnumerable<X> XsIncludingYs { get; }

    X XById{ get; }
}