多参数组合查询场景下避免大量if-else的设计模式选型

Great question! This is a super common pain point when dealing with dynamic query parameters—those endless if-else chains get unmanageable fast, especially when you know more parameters might be added later.

The best approach here is to use the Builder Pattern combined with dynamic query construction (like JPA's Criteria API, Spring Data's Example queries, or QueryDSL) to eliminate all those redundant condition checks. Let me break this down for you:

Why Your Current Approach Is Problematic #

Your existing code suffers from:

• Exponential complexity: Each new parameter doubles the number of possible condition combinations, leading to a maintenance nightmare.
• Violation of the Open/Closed Principle: Adding a new parameter requires modifying the existing method and creating new repository methods.
• Poor readability: It's hard to parse which parameters map to which query at a glance.

Solution 1: Use Spring Data JPA's Criteria API with a Query Builder #

This approach encapsulates query condition building in a dedicated builder class, making your code scalable and clean.

Step 1: Update Your Repository #

First, extend JpaSpecificationExecutor to enable dynamic query support:

public interface FooRepository extends JpaRepository<Foo, Long>, JpaSpecificationExecutor<Foo> {
}

Step 2: Create a Query Builder Class #

This class handles parameter validation and builds the dynamic query specification:

public class FooQueryBuilder {
    private String a;
    private String b;
    private String c;

    // Fluent setter methods that skip empty/null values
    public FooQueryBuilder withA(String a) {
        if (a != null && !a.isBlank()) {
            this.a = a;
        }
        return this;
    }

    public FooQueryBuilder withB(String b) {
        if (b != null && !b.isBlank()) {
            this.b = b;
        }
        return this;
    }

    public FooQueryBuilder withC(String c) {
        if (c != null && !c.isBlank()) {
            this.c = c;
        }
        return this;
    }

    // Build the Specification for JPA
    public Specification<Foo> build() {
        return (root, query, criteriaBuilder) -> {
            List<Predicate> predicates = new ArrayList<>();
            
            // Add conditions only for non-null/non-empty parameters
            if (a != null) {
                predicates.add(criteriaBuilder.equal(root.get("a"), a));
            }
            if (b != null) {
                predicates.add(criteriaBuilder.equal(root.get("b"), b));
            }
            if (c != null) {
                predicates.add(criteriaBuilder.equal(root.get("c"), c));
            }

            // Combine all predicates with AND logic
            return criteriaBuilder.and(predicates.toArray(new Predicate[0]));
        };
    }
}

Step 3: Simplify Your Service Method #

Now your service method becomes clean and scalable:

public Foo getFoo(String a, String b, String c) {
    FooQueryBuilder queryBuilder = new FooQueryBuilder()
            .withA(a)
            .withB(b)
            .withC(c);

    // Execute the dynamic query
    return fooRepository.findOne(queryBuilder.build())
            .orElse(null); // Handle empty result as needed
}

Solution 2: Spring Data Example Queries (Simpler for Basic Cases) #

If your queries are simple (equality checks only), Spring Data's Example API is even more concise:

public Foo getFoo(String a, String b, String c) {
    // Create a probe object with only non-null/non-empty parameters
    Foo probe = new Foo();
    if (a != null && !a.isBlank()) probe.setA(a);
    if (b != null && !b.isBlank()) probe.setB(b);
    if (c != null && !c.isBlank()) probe.setC(c);

    // Configure matcher to ignore null/empty values
    ExampleMatcher matcher = ExampleMatcher.matching()
            .withIgnoreNullValues()
            .withIgnorePaths("id"); // Ignore primary key or other irrelevant fields

    Example<Foo> example = Example.of(probe, matcher);
    return fooRepository.findOne(example).orElse(null);
}

Key Benefits of These Approaches #

• No more if-else chains: Query conditions are built dynamically based on valid parameters.
• Easy scalability: Adding a new parameter only requires updating the builder (or probe object) — no changes to service logic or new repository methods.
• Cleaner code: Query logic is centralized, making it easier to debug and maintain.
• Flexibility: The Criteria API approach supports complex queries (like greater-than, contains, or OR logic) if your requirements evolve.

内容的提问来源于stack exchange，提问作者Arielo