skip to content

As an architect, how do you choose among Query by Example, Querydsl, Specifications, and derived/@Query methods for dynamic querying?

level: principalimportance: should knowfreq 35%

answer

  1. two axes: expressiveness vs build/maintenance cost
  2. fixed→@Query/derived; simple dynamic→QBE
  3. rich dynamic no-codegen→Specifications
  4. rich dynamic ergonomic type-safe→Querydsl
  5. hide Predicate/Spec behind repo fragments; standardize one

basics

~20 s

Match the tool to the query's complexity and team cost. QBE: simple equality/LIKE search forms, zero codegen. Specifications: dynamic JPA-Criteria logic, no extra build step. Querydsl: rich type-safe dynamic queries but needs codegen. @Query/derived: fixed, known queries.

solid answer

~50 s

I choose along two axes: expressiveness needed and build/maintenance cost. For fixed, well-known queries, derived methods or @Query are clearest — no abstraction tax. For dynamic filters: Query by Example is the lightest — no extra dependency, but limited to equality/LIKE on non-null fields, so only for uniform search forms. JPA Specifications (JpaSpecificationExecutor) express arbitrary Criteria logic (ranges, OR, joins) with composable and()/or(), no code generation, but the Criteria API is verbose and stringly-typed for paths unless you use the metamodel. Querydsl gives the most ergonomic, fully type-safe dynamic queries (BooleanBuilder for optional filters, ranges, IN, nested paths) at the cost of annotation-processor codegen and a dependency that leaks Predicate types into callers. I also weigh consistency: pick one primary approach per codebase to reduce cognitive load, and localize predicate/spec building behind repository fragments so the query library doesn't bleed into services.

code

java · 12 lines
java
// Specifications: full Criteria power, no codegen, but string paths
Specification<Person> spec = Specification.where(null);
if (city != null)   spec = spec.and((r, q, cb) -> cb.equal(r.get("city"), city));
if (minAge != null) spec = spec.and((r, q, cb) -> cb.ge(r.get("age"), minAge));
List<Person> a = specRepo.findAll(spec);   // extends JpaSpecificationExecutor

// Querydsl: same query, fully type-safe, needs generated QPerson
QPerson p = QPerson.person;
BooleanBuilder b = new BooleanBuilder();
if (city != null)   b.and(p.city.eq(city));
if (minAge != null) b.and(p.age.goe(minAge));
List<Person> c = qdslRepo.findAll(b);      // extends QuerydslPredicateExecutor

go deeper

for a junior

Typically knows only derived methods and @Query.

for a middle

Can use Specifications or Querydsl but may not articulate the trade-offs between them.

for a senior

Compares all four accurately and picks appropriately per use case.

for a principal

Reasons about codebase-wide consistency, layer encapsulation of query types, build/tooling cost, and total cost of ownership — not just local query fit.

Spring Data offers four main ways to query, and the architect's job is to pick per *use case* while keeping the codebase coherent. **1. Derived query methods** (`findByLastNameAndCity`) and **`@Query`** (JPQL/native): - Best for **fixed, known** queries. Zero runtime assembly, self-documenting, easy to read. - Weak for **dynamic** filters: you'd need a combinatorial explosion of methods or messy JPQL with many `(:param IS NULL OR col = :param)` clauses. **2. Query by Example** (`QueryByExampleExecutor`, `Example`, `ExampleMatcher`): - **Pros:** no extra dependency, no codegen, refactor-safe (uses the entity itself), trivial to wire a search form where the user fills arbitrary fields. - **Cons:** only **equality and string LIKE**; no ranges, `IN`, negation, arbitrary OR, or deep association logic; primitive gotcha; nested matching limited. - **Use when:** the filter set is a handful of string/exact fields and the UX is 'fill what you know'. **3. JPA Specifications** (`JpaSpecificationExecutor<T>`, `Specification<T>`): - A `Specification` is a lambda producing a JPA Criteria `Predicate` from `(root, query, criteriaBuilder)`. They **compose** with `Specification.where(a).and(b).or(c)` and support the **full Criteria API**: ranges, joins, subqueries, `in`, negation, grouping. - **Pros:** no build-time codegen (pure runtime), reusable named specs form a small domain vocabulary, part of core Spring Data JPA. - **Cons:** the Criteria API is **verbose**; property paths are **string-based** (`root.get("age")`) unless you generate/consume the JPA **static metamodel** (`Person_.age`), which itself needs an annotation processor. Harder to read than Querydsl for complex expressions. **4. Querydsl** (`QuerydslPredicateExecutor<T>`, generated `Q`-types, `Predicate`/`BooleanBuilder`): - **Pros:** the most **fluent and fully type-safe** dynamic queries; `BooleanBuilder` cleanly assembles only the filters present; ranges/IN/OR/nested paths all first-class; typed sorting via `OrderSpecifier`; optional `@QuerydslPredicate` web binding. - **Cons:** **annotation-processor codegen** (Q-types must regen on entity change; classifier/wiring pitfalls on Jakarta/Boot 3); extra dependency; `Predicate` types can **leak into service layers**, coupling them to Querydsl. **Decision framework:** - *Query shape known & static* → derived / `@Query`. - *Dynamic but only equality/LIKE on a few fields* → **QBE**. - *Dynamic with rich logic, want to stay within core Spring Data JPA, no codegen appetite* → **Specifications** (add the metamodel for type safety). - *Dynamic with rich logic and you value ergonomics/type safety enough to adopt codegen* → **Querydsl**. - *Need DTO projections, joins with select, bulk update/delete* → drop to **`JPAQueryFactory`** (full Querydsl) or `@Query`. **Cross-cutting architectural concerns:** - **Consistency over local optimality:** two dynamic-query mechanisms in one codebase doubles the learning curve; standardize on one primary (commonly Querydsl or Specifications) and reserve QBE for the odd simple form. - **Encapsulation:** keep spec/predicate construction inside **custom repository fragments** so services depend on domain-meaningful methods, not on `Specification`/`Predicate` — preventing the query library from leaking across layers. - **Build & tooling cost:** Querydsl/metamodel codegen affects CI, IDE setup, and upgrade friction (e.g., Jakarta migration). Factor that into total cost of ownership. - **Testing & performance:** all four ultimately hit the same SQL generation; profile N+1 and fetch strategies regardless of the DSL chosen.

  • Specifications vs Querydsl — the single biggest practical trade-off?
    Type safety vs build simplicity. Querydsl's generated Q-types make paths compile-safe and the DSL more readable, but require annotation-processor codegen. Specifications need no codegen and live in core Spring Data JPA, but use string-based Criteria paths (verbose, refactor-fragile) unless you add the JPA static metamodel, which reintroduces a processor.
  • How do you stop the query library from leaking across architectural layers?
    Encapsulate spec/predicate construction inside custom repository fragment implementations exposing intention-revealing methods (e.g., searchActiveInCity(...)). Services call those and never see Specification or Predicate, so the persistence tech stays swappable and layers stay decoupled.
  • When would you skip all four and use JPAQueryFactory or native SQL?
    When you need DTO/tuple projections, complex joins with explicit selects, window functions, bulk update/delete, or database-specific SQL — cases beyond predicate-based entity finds. JPAQueryFactory gives the full Querydsl query API; native @Query handles vendor-specific SQL.

saying these in an interview costs you the question

  • Advocating multiple dynamic-query DSLs in one codebase without a consistency rationale
  • Claiming Specifications need Querydsl-style codegen (they don't, unless you add the metamodel)
  • Letting Specification/Predicate types leak into the service layer
  • Using QBE for range/OR queries it cannot express

context

resolving links…