views:

293

answers:

2

I'm currently thinking about a repository pattern for my data objects, where multiple IQueryable<> instances can be registered as data sources. But it seems its not so easy to get it running :-)

Running a simple LinQ Query with Linq to entities and linq to objects doesnt work. Do you think this is in general possible? Maybe the only solution is to write a specified provider?!

Remarks: In my repository i called .Union<> on all my IQueryable instances and then finally used LinQ for a query on the resulting single IQueryable. The result was that one IQueryable was ignored completely.

A: 

Well, I use LINQ queries on lists, collections a whole bunch of stuff. I use very similar queries on SQL tables. I never had any problems. I have heard of people having some issues using LINQ queries on LINQ to objects, but I think they're generally considered as LINQ bugs rather than by design differences in the the way LINQ to objects, LINQ to XML and LINQ to SQL works. I did have some LINQ issues back in the days before I installed VS 2008 SP1, but they've since been resolved.

So long as you take into account what the query is returning, it should work just fine.

BenAlabaster
A: 

I have absolutely no documentation to back this up, but I do recall some discussion in the pre-release days about optimizations that were being built into Linq to SQL which would attempt to eliminate multiple calls to the database when performing operations on Linq to SQL IQueryable<> objects and Linq to Object IQueryable<> objects. This, combined with the overall architecture of the IQueryable interfaces, makes me think that there should be no issue operating on different providers. It seems possible, though, that the ability to interact may be based on the specific implementation of the provider.

I know I have operated on combinations of Linq to Object and Linq to XML collections without issue.

ckramer
LINQ to Objects doesn't use IQueryable. I'm not sure what you're talking about.
Barry Kelly