Query Object Pattern vs LINQ

I am busy with a new project and am working on my repository layer. This will be my 2nd project using the Repository Pattern. I have been reading Scott Millett's book Professional ASP.NET Design Patterns In referencing the case study in the book, Scott has used t开发者_如何转开发he Query Object Pattern in in his repository interfaces. In my previous project I used LINQ for this purpose and it worked well.

My question is as follows: What are the pros and cons of using a Query Object Pattern implementation versus using LINQ in your repository?

Here are 2 scenarios which illustrate the 2 different approaches:

1. Query Object Pattern approach

public interface IReadOnlyRepository<T, TId> where T : IAggregateRoot
{
    T FindBy(TId id);
    IEnumerable<T> FindAll();
    IEnumerable<T> FindBy(Query query);
}

2. LINQ approach

public interface IReadOnlyRepository<T, TId> where T : IAggregateRoot
{
    T FindBy(TId id);
    IQueryable<T> FindAll();
    IQueryable<T> FindBy(Expression<Func<T, bool>> query);
}

Any contributions would be helpful.

Although I think the expression trees of LINQ are just a special form of the query object pattern, because of their greater flexibility, they allow you to introduce bugs in your code that only are visible at runtime. I am talking about C# code that gets successfully converted to an expression tree, but is not understood by the provider that is supposed to translate it to SQL.

Example:

var a = new SpecialObject();
yourRepository.FindBy(x => a.IsCorrect(x));

An error like this would be impossible with an ordinary query object.