IQueryable is a FATTY!

written by tobinharris on October 20th, 2008 @ 05:41 AM

I probably missed the point here, but IQueryable seems to be rather bloated!?

Couldn't it be more fine grained ilke this?

public interface IQueryable<T> 
                          : IPagable<T>, 
                            IListable<T>, 
                            IAggregatable<T>, 
                            ISetOperable<T> ...
{
    //....
}

public interface IPagable<T>
{
    IPageable<T> Skip( long records );
    IPageable<T> Take( long records );
}

public interface IListable<T>
{ 
    IList<T> ToList();
}

// ...
//

This way our applications could depend on subsets of the IQueryable methods. And yeah, I realise that the above won't actually work, but you get the idea :)

Is something like this possible already, or am I just being dim!?



kick it on DotNetKicks.com



Comments

  • Fabrice on 21 Oct 01:15

    Hum, well, IQueryable<t> contains one method and three methods, so it’s not that bloated.

  • Fabrice on 21 Oct 01:15

    I mean “one method and three properties”, of course.

  • Tobin Harris on 21 Oct 06:57

    Fabrice, I wondered if you’d notice this error (or if someone would) :)

    My brief exploration the object browser revealed that IQueryable is as light as you say. But, the Queryable class has all those extension methods against it. I just thought I’d stick them all under one roof for arguments sake.

    So, when someone tries to implement a custom Linq implementation, I take it they have to override all those extension methods?

    What I’m driving at is, can we exploit a subset of those methods in any way without causing confusion?

  • Fabrice on 21 Oct 17:39

    You don’t have to override the extension methods. They are not part of the interface. When you implement IQueryable, you have to implement its four members, and you have to handle some or all of the extension methods. It’s up to you. It’s not required that your implementation handles all the query operators. For example, a specific implementation may not handle the Skip or OrderBy query operators. If you take a look at LINQ to Amazon, which is not a complete implementation but remains a sample, you’ll see that it doesn’t handle much more than the Where query operator.

    The problem, as you suggest, is confusion. If your implementation does not support some query operators, this does not prevent a developer from trying to use them because all the extension methods exist. It’s at run-time that your implementation will throw an exception to state that it doesn’t handle operators X or Y. But it won’t always be because your implementation is not complete. In some cases, it’s just not possible to implement all the query operators, simply because the underlying service or data source does not offer support for certain operations (think about grouping or join operations with Amazon, for example).

    I invite anyone who’d like more information about this to refer to chapter 12 of LINQ in Action ;-)

  • Tobin Harris on 21 Oct 18:14

    Thanks Fabrice, that’s very useful. I’m pondering doing a really partial implementation for NHibernate, so I can get database paging for HQL queries:

    var found = _session.HqlLinq<customer>("from h in Customer where h.Name = 'tobin'").Skip(10).Take(10)

    Behind the scenes this calls:

    var q = _session.CreateQuery(hql);
    q.SetStart(10);
    q.SetMaxRecords(10);

    Am gonna read more of your book and see what comes up.

    PS. You can plug your book on my site anytime too, it’s great :-)

Post a comment

Options:

Size

Colors