《Elasticsearch通用查询方案（二）：QueryConditionBuilders 工具类》

本文链接：https://blog.csdn.net/java_devForMySelf/article/details/144432641

Elasticsearch通用查询方案

《通用查询方案（一）：开篇与基础概念》

《通用查询方案（二）：QueryConditionBuilders 工具类》

《通用查询方案（三）：QueryBuilderFactory 组件》

《通用查询方案（四）：QueryCondition 使用指南与实战》

文章目录

Elasticsearch通用查询方案
引言
一、QueryConditionBuilders 工具类概述
二、部分代码示例
三、create 方法的魔力
四、与整体技术方案的协同
总结

引言

在上一篇文章中，我们了解了通用接口查询技术方案的基本概念，知晓了什么是**词汇表和容器**。这些为我们构建查询条件奠定了基础，但在实际开发中，手动创建各种查询条件类的实例可能会变得繁琐且容易出错。为了解决这个问题，我们引入了 QueryConditionBuilders 工具类。在本篇文章中，我们将深入探讨这个工具类的功能和使用方法。

提示：以下是本篇文章正文内容，下面案例可供参考

一、QueryConditionBuilders 工具类概述

在通用接口查询的技术版图中，QueryConditionBuilders 无疑是一位幕后的关键 “工匠”，其首要且核心的职责是作为查询条件的创建工厂。
QueryConditionBuilders 是一个专门设计用于简化查询条件构建过程的工具类。它提供了一系列静态方法，通过标准化、集中化的方式，使得开发者能够根据不同的操作符和参数快速创建相应的 QueryCondition 对象，而无需直接实例化各个具体的查询条件类，避免了在代码各处散落不同查询条件构建逻辑所导致的混乱与难以维护。这不仅提高了开发效率，还增强了代码的一致性和可维护性；
无论是简单的精确匹配，还是复杂的范围查询、嵌套查询起始条件，都能借助它有条不紊地构建出来，为后续构建完整查询请求奠定坚实基础。

二、部分代码示例

代码如下（其他没有的需要自己拓展）：

public class QueryConditionBuilders {

    // 私有构造函数，防止类被实例化
    private QueryConditionBuilders() {}

    /**
     * 根据给定的操作符、字段名和操作数创建对应的QueryCondition对象。
     *
     * @param operator 操作符，从OperatorEnum枚举中选取相应的值，用于指定查询条件的类型，如精确匹配、范围查询等。
     * @param field 字段名，指定要进行查询操作的目标字段，例如在数据库表中的列名。
     * @param operand 操作数，根据操作符的不同，其类型和含义有所变化，比如对于精确匹配可能是一个具体的值，对于范围查询可能是一个包含边界值的数组等。
     * @return 创建好的QueryCondition对象，封装了查询条件的相关信息。
     */
    public static QueryCondition create(OperatorEnum operator, String field, Object operand) {
        switch (operator) {
            case EQ:
                return new QueryCondition(field, operator, operand, false);
            case GT:
                return new QueryCondition(field, operator, operand, false);
            case GTE:
                return new QueryCondition(field, operator, operand, false);
            case LT:
                return new QueryCondition(field, operator, operand, false);
            case LTE:
                return new QueryCondition(field, operator, operand, false);
            case NOT_IN:
                if (!(operand instanceof List)) {
                    throw new IllegalArgumentException("NOT_IN操作符的操作数必须是列表类型");
                }
                return new QueryCondition(field, operator, operand, false);
            case IN:
                if (!(operand instanceof List)) {
                    throw new IllegalArgumentException("IN操作符的操作数必须是列表类型");
                }
                return new QueryCondition(field, operator, operand, false);
            case RANGE:
                if (!(operand instanceof List)) {
                    throw new IllegalArgumentException("RANGE操作符的操作数必须是列表类型");
                }
                return new QueryCondition(field, operator, operand, false);
            case WILDCARD:
                return new QueryCondition(field, operator, operand, false);
            case CONTAINS:
                return new QueryCondition(field, operator, operand, false);
            case EXISTS:
                return new QueryCondition(field, operator, operand, false);
            case MUST:
                if (!(operand instanceof List)) {
                    throw new IllegalArgumentException("MUST操作符的操作数必须是QueryCondition列表");
                }
                return new QueryCondition(field, operator, new ArrayList<>((List<QueryCondition>) operand), true);
            case MUST_NOT:
                if (!(operand instanceof List)) {
                    throw new IllegalArgumentException("MUST操作符的操作数必须是QueryCondition列表");
                }
                return new QueryCondition(field, operator, new ArrayList<>((List<QueryCondition>) operand), true);
            case SHOULD:
                if (!(operand instanceof List)) {
                    throw new IllegalArgumentException("SHOULD操作符的操作数必须是QueryCondition列表");
                }
                return new QueryCondition(field, operator, new ArrayList<>((List<QueryCondition>) operand), true);
            default:
                throw new IllegalArgumentException("不支持的操作符: " + operator.getCode());
        }
    }
}

三、create 方法的魔力

当外界传入一个操作符（来自精心设计的 OperatorEnum 枚举，涵盖 EQ、GT、GTE、LT、LTE、NOT_IN、IN、RANGE、WILDCARD、CONTAINS、EXISTS、MUST、MUST_NOT、SHOULD、NESTED_EQ、NE 等丰富类型）、对应的字段名以及操作数时，一场 “条件构建魔法秀” 便悄然开场。

以常见的 EQ（精确匹配）操作符为例，当 create 方法识别到传入的是 EQ 操作符，它会迅速实例化一个 QueryCondition 对象，将传入的字段名精准赋值给对象的 field 属性，把操作符本身设置到 operator 属性，同时把操作数妥善安置在 operand 属性位置，确保这个对象完整无误地承载了精确匹配的查询意图。

QueryCondition eqCondition = QueryConditionBuilders.create(OperatorEnum.EQ, "productName", "iPhone 13");

而面对诸如 RANGE 这样相对复杂的操作符时，create 方法则展现出严谨的一面。它不仅要实例化 QueryCondition 对象，还会对传入的操作数进行严格校验。假设操作数应该是一个特定格式的数组，比如 [下限值，是否包含下限，上限值，是否包含上限]，方法会细致检查数组长度是否合规、元素类型是否匹配等，只有一切校验通过，才会完成对象构建，保证后续基于此条件的查询不会因数据问题而 “跑偏”。

QueryCondition rangeCondition = QueryConditionBuilders.create(OperatorEnum.RANGE, "age", new Object[]{20, true, 30, false});

四、与整体技术方案的协同

QueryConditionBuilders 并非孤立存在，它与整个通用接口查询技术方案中的其他组件紧密配合，奏响和谐的查询 “交响乐”。构建好的 QueryCondition 对象会被传递给后续的组件，后者利用这些 “零件” 组装出完整的、适配Elasticsearch语法的查询构建器，进而执行查询操作