Guidance on executing queries from UI layer

Question

I'm trying to establish a convention on how to execute queries from our UI (controllers) layer. Here are my three options:

1. Wrap each query into its own query object. (seems to lead to class explosion but better encapsulation).
2. Provide a service facade layer in order to group related queries together. (breaks SRP and sprinkles caching throughout. caching decorator makes more painful when not all query methods need caching.)
3. Provide an IDbReadContext that wraps EF or whatever. (exposes IQueryable which could or couldn't be bad. also gives no one point of caching since multiple objects could be running the same queries.

Any guidance or suggestions would be great!

Answer 1

I tend to use a class per query, as I find several advantages to it. Each query class follows the single responsibility principle better, but also follows the open-closed principle better as well - it is easier to make changes in a system by adding new code and not changing existing code when each query is encapsulated in its own class. It is also easier to systematically apply cross-cutting behaviors like logging, authorization, and caching using aspect-oriented techniques when each query is its own class.

On occasion, I will design a single query class with multiple overloads for calling the query with different sets of parameters, but I try to do this only when the result is logically the same only retrieved from slightly different contexts - the amount of reusability between the overloads is a good indication of whet