Generic Entity Framework Query in CQRS I've been working on our application (CQRS and DDD) for awhile now. The application architecture is well layered and thought through.

However we are having difficulties in decide where to put the below code, in such a way that it makes sense from an architectural point of view.

What the code does: It's a generic method which executes a query against the dataset, specified by the generic parameter which inherits a particular interface.
Note: we are not using repositories, since the query is, as the name indicates, for our read layer.

The interface, used by the generic method:

public interface IOrganisationalDbEntry
{
    string OrganisationLevelId { get; set; }
    OrganisationLevelDbEntry OrganisationLevel { get; set; }
}


The generic method, which lives inside our Entity Framework DbContext:

public IList&lt;TDbEntry&gt; GetByOrganisationLevel&lt;TDbEntry&gt;(Guid? organisationLevelId,
    Func&lt;TDbEntry, bool&gt; filter = null)
    where TDbEntry : class, IOrganisationalDbEntry
{
    var organisationLevel = organisationLevelId.HasValue ? organisationLevelId.Value.ToString() : null;

    var query = filter == null ? Set&lt;TDbEntry&gt;() : Set&lt;TDbEntry&gt;().Where(filter);

    IList&lt;TDbEntry&gt; result = query.Where(x =&gt; x.OrganisationLevelId == organisationLevel).ToList();

    // If there are no results for the current organisation level
    // =&gt; recursive check for entries for parent organisation level
    if (!result.Any() &amp;&amp; !string.IsNullOrWhiteSpace(organisationLevel))
    {
        // Get parentOrganisationLevel
        var parentOrganisationLevelId = Set&lt;OrganisationLevelDbEntry&gt;()
            .Where(x =&gt; x.Id == organisationLevel)
            .Select(x =&gt; x.ParentOrganisationLevelId)
            .SingleOrDefault();

        return
            GetByOrganisationLevel&lt;TDbEntry&gt;(
                string.IsNullOrWhiteSpace(parentOrganisationLevelId)
                    ? (Guid?)null
                    : new Guid(parentOrganisationLevelId), filter);
    }

    return result;
}


As you may be thinking, we have several EF Entities inheriting the IOrganisationalDbEntry. What comes to mind first, is a base Repository. But We do not want to use repositories in our query side, since we want this layer to be as flat as possible. 

The next thing that comes to mind is a specific query and queryhandler for this query. Tho this is not acceptable since this method accepts a Func parameter to be able to add extra filter criteria while calling this method, to make it more flexible.

At this moment, this method is living as method on our IDbContext and DbContext implementation. However we are not satisfied with this.  We are wondering whether there is a specific pattern or approach for our case.  Imagine we have more of these methods, I do not want to keep expanding our context. Since this is not what the DbContext should be used for.

EDIT: Everywhere you read CQRS in the above question , replace it by CQS. I didn't want to modify the question since it would make some comments irrelavant.
I'll give it a shot since CQRS is something I'm still learning.

In CQRS we are supposed to separate our read model from our write model. Is this what you have done?

Then the read model should be designed to be a perfect fit for the thing that needs to read it:


Your query looks very complex. Is it derived from the write model, or do you indeed have separate tables for the queries?
Why a Func as a parameter? It seems strange to me that the criteria should be a negotiation between client and query.
Why do you put the query method onto the DbContext? That class will soon enough be cluttered with too many queries.


Here are some suggestions to simplify things:


Let the DbContext mimic the database tables only and nothing else. That means your DbContext will only have public properties for the tables you are going to query.
Don't call it a Repository, but a Query. Split the Query-class when it grows too big.
Let the Query class take the DbContext as a dependency. Query the DbContext-properties, don't use Set&lt;T&gt;.
Let each query-method accept one criteria object as parameter, then build the query expression from that inside the method.
Linq is tricky. While not entirely true, a rule of thumb is that a Func runs client side, while an Expression runs server side. That's also why I don't like the Func-parameter.
Consider using only non-generic query-methods. Yes, there will be some duplication, but you want your peers and the future you to understand the queries two months from now.


I meant to post some code examples, but Chrome crashed again and edits got lost :-(