Generic version of Query

Consider the following:

var query = new Query(typeof (Data.Registration), Entity.Attribute("ConfirmationCode") == id || Entity.Attribute("Id") == id);
var registration = UnitOfWork.FindOne<Data.Registration>(query);

Notice how many times the type for registration is specified. Is there perhaps a chance that we can have a generic Query like this:

public class Query<T> : Query
    where T : Entity
{
    public Query()
        : base(typeof (T))
    {
    }

    public Query(QueryExpression queryExpression)
        : base(typeof (T), queryExpression)
    {
    }
}

And have an overload of Find, FindOne and supporting methods looking similar to this:

IList<T> Find(Query<T> query)
T FindOne(Query<T> query)

Then the usage looks as follows:

var query = new Query<Data.Registration>(Entity.Attribute("ConfirmationCode") == id || Entity.Attribute("Id") == id);
var registration = UnitOfWork.FindOne(query);

The benefit is that the type is validated (and if ReSharper screws up my references, I'll know), and I only have to specify the type once. The problem I have is that every now and then the wrong "type" is passed as the type parameter and introduces bugs.

Thanks, Werner

I only use the Query functions when I don't know the type ahead of time. I constantly burn myself with LINQ (through a combination of personal incompetence and lots of sharp corners in Lightspeed) but:

var registration = UnitOfWork.Registrations.First(x=> x.ConfirmationCode == id || x.Id == id);

... is my friend.

Also note you can use Data.Registration.ConfirmationCodeField instead of "ConfirmationCode" in recent builds for additional compile time checking.

I don't use LINQ for reasons of reuse as I use generics and interfaces a lot. LINQ and interfaces do not play well. This is why I originally requested the feature to inject queries based on interfaces, so I can reduce the complexity of the system.

This request is to make it easier to work with generics within LightSpeed and the query was an over simplified example.

Werner

LINQ and interfaces play great so long as your interface is IQueryable. :)

Playing off LINQ (say, for adding custom sort) led me down a quick path of Lightspeed bugs, LINQ inconsistencies, and an inability to predict which parts of a query would execute in the database or on the server. And not even the wizards at StackOverflow have come up with a way to parameterize multiple orderby columns yet.

In contrast, I find the Query interface predictable if a bit verbose. And yeah, there are already generics on things like Query.Join so why not.

This is how many of my entities look like:

class MyEntity : Entity<long>, IConfirmable, ISecurable, IExpireable
{
  /* some implementation */
}

class MyEntity2 : Entity<long>, IExpireable
{
  /* some implementation */
}

I find writing LINQ queries that rely on properties on the interface caused problems for LightSpeed (and EF).

The typeof(Data.Registration) in your Query object is superfluous. When you issue the strong typed FindOne<T> or Find<T>, LightSpeed automatically knows that the query applies to the specified type, so you do not need to specify it in the Query object. I.e. the following works fine:

var query = new Query(Entity.Attribute("ConfirmationCode") == id || Entity.Attribute("Id") == id);
var registration = UnitOfWork.FindOne<Data.Registration>(query);

and specifies the type only once.

You only need to specify the type in the Query object if you are calling a method that does not specify the entity type itself, e.g. IUnitOfWork.Project(Query).

Excellent. I didn't know that.