EasySearch

1 什么是EasySearch

EasySearch用中文表述可以称之为动态数据源，它在最初只是作为控件单选搜索框的数据来源，而单选搜索框的控件英文名称就是EasySearch，所以当时直接将其数据源类型命名为EasySearch。使用它的主要目的是为了解决部分数据源的数据量较大，前端选项无法一次性加载显示，选项较多需要结合名称关键字搜索或按类型区分这一类共性问题。同时它也结合了树型数据结构部分特性，支持让数据在树形和列表两种结构之间转换。

EasySearch内部还会细分多种类型，基于数据结构我们可以将其分为：

• 列表EasySearch
• 树型EasySearch

基于数据来源不同，我们可以将其分为：

• 基于元数据的EasySearch
• 基于数据视图的EasySearch

2 EasySearch特性

EasySearch本身作为动态数据源，具有以下四种特性：

定量加载数据

不同于CodeTable是全量加载数据（CodeTable也限制总数但是基数较EasySearch大很多），EasySearch加载数据时只加载前N条数据（默认是前15条），并且是在点击控件时实时加载，所以在无关键字时，需要注意它的选项并非只有N条，而是只加载前N条。
加载数据除了受数量限制外，还受到过滤条件，数据权限的限制，且选项的名称字段不能为空，如果其来源于元数据，那么也受元数据的假删除和过滤条件的限制。

可搜索

由于EasySearch是实时加载数据，所以用户可以数据关键字实时查询对应选项，关键字搜索具有一定的策略
当字符包含中文时认定为名称关键字
当字符都是字母时认定简码关键字
其他情况认定为编码关键字
当前查询策略为：

• 如果关键字是名称，则直接搜索名称字段
• 如果关键字是简码或者编码，则判定是否配置简码字段
• 如果简码字段存在则同时搜索简码和名称
• 如果不存在则只搜索名称字段

数据解码

EasySearch和CodeTable同时具备解码功能，但是其内部原理并不一致
EasySearch解码时，会根据编码查询对应数据，如果编码存在对应数据，则会将解码过的值存入临时缓存，该临时缓存在页面访问完成后就会销毁，如果用户开启了缓存功能，则会在解码后同步将数据保存至服务器缓存，该缓存的生命周期受设计者指定的时间控制
用户可以在设计器中分开配置控件对应的数据源和解码数据，其目的在于解决用户的可见范围要大于可选范围这种情况

联动填充

由于EasySerch是动态实时加载数据的，所以可以做到根据其他控件值进行联动的操作，以“省市区”为例，需要先选择“省”，才能显示对应“市”数据，“区”同理
EasySearch可以在联动配置中，关联元数据的其他字段，根据其他字段值进行数据过虑
EasySearch和CodeTable一样具备将数据源的其他字段填充到当前元数据字段的功能

3 有哪些EasySearch

基于元数据的EasySearch
来源于元数据的EasySearch，会优先使用元数据指定的编码和名称字段，如果未指定，则需要设计者指定对应字段
元数据本身自带的假删除和过滤条件也会在对应EasySerch中起效

基于数据视图的EasySearch
数据视图本身作为一种数据源，可以通过包装代理的方式，将其包装成EasySearch
相较于基于元数据的EasySearch，数据视图的EasySearch具有更大的灵活性，但同时也提高了使用门槛
以SQL数据视图为例，查询返回数据字段必须包含名称字段和编码字段，为了实现解码功能，必须配置解码参数，同时为了实现搜索功能，还需要提供搜索参数
下面是一个基本的SQL示例，可转换成基本的EasySearch：

SELECT 
    `id_codeid`.`ID`, 
    `id_codeid`.`ID_NAME`, 
    `id_codeid`.`ID_VALUE`, 
    `id_codeid`.`ID_PRE`, 
    `id_codeid`.`ID_DATE_FLAG`, 
    `id_codeid`.`ID_LENGTH`
FROM 
    `id_codeid`
WHERE 
    `id_codeid`.`ID` = {id}  ## 编码参数
     AND  `id_codeid`.`ID_NAME` LIKE '%{name}%' ## 搜索参数

根据以上示例，数据视图想作为EasySearch数据源，至少需要添加两个参数，解码参数只在解码时起效，搜索参数只在查询时起效
如果还想做联动，必须提供其它参数辅助

元数据标准树的EasySearch
标准树EasySearch基于元数据的树定义，除了编码，名称，父编码，叶子节点以外还有一个层码字段，该字段必须使用树模型进行数据维护，主要用于数据排序，快速定位，子数据查询
标准树的数据查询和列表数据查询都需要依赖层码字段
标准树支持数据联动，联动本身以查询根节点的形式呈现，即联动条件只在根节点查询时起效
同时标准树在展示成列表时，也会受到根节点以及只选叶子节点功能的限制

元数据简单树的EasySearch
简单树本质上时标准树的劣化版，其本身的特性基本与标准树一致，但是缺失了关键的层码字段
由于层码缺失，简单树无法执行联动过滤根节点的操作，所以简单树不支持联动过滤
简单树的是否叶子节点是可选字段，如果未选择该字段则无法判定节点是否叶子节点（如果每个节点都去数据库里查，效率会很低）
数据视图简单树的EasySearch
通过数据视图构造的简单树EasySearch，支持简单树的基础功能，其本身的编码，名称，父编码，是否叶子节点这些搜索是通过数据视图的参数功能实现的，所以这些参数不可缺少，否则一些基础功能会受到影响
以基础的SQL数据视图为例：

SELECT 
    `sys_organization`.`ORG_ID`, ## 编码字段
    `sys_organization`.`ORG_NAME`,## 名称字段
    `sys_organization`.`ORG_PARENT_ID`, ## 父编码字段
    `sys_organization`.`ORG_IS_LEAF` ## 是否叶子节点字段
FROM 
    `sys_organization` where ORG_ID = '{orgId}' ## 解码参数
    AND ORG_NAME like '%{orgName}%' ## 搜索参数
    AND ORG_IS_LEAF  = {leaf} ## 是否叶子节点
    AND ORG_PARENT_ID = '{parentId}' ## 父编码参数

由于这类EasySearch完全依赖数据视图的功能，所以对数据视图本身的配置有一些要求
基于数据视图的简单树EasySearch与元数据的简单树有一定区别，在于联动时，它还是会把联动条件一并传给数据源，且每次请求数据都会发送，所以对于这类树，联动是有效的，但是在实际使用中，由于树即能以树的形式展现，又能以列表形式展现，过滤时，可能会将无法在树中展示的数据加载到列表中。

4 常见问题

1. 控件数据为什么不显示
   一般是由于取数时出现异常导致，可能原因有：

• 数据库链接异常
• SQL执行异常
• 数据存在数据权限等过滤机制
• 配置错误等

一般的解决方式：开启模版的调试模式，触发取数，然后查看日志，确认对应问题即可。

2. 解码失败的原因
   一般的解码失败原因只会是编码值对应的显示值不存在，
   或者配置了错误的解码数据源，也会出现该问题。
   值得注意的是：数据视图的数据源如果未配置解码参数，可能造成解码错误，即永远显示第一个解码值。

3. 数据类型不匹配
   一般来讲字段控件配置了数据源，那么其字段类型应当与数据源的编码值类型保持一致，但是某些特殊情况下，两者类型不一致，就有可能出现数据类型不匹配的情况，如：编码值是整形数值，但是字段值是字符串，那么当字符串的值传递给数据源进行解码时，有可能出现数据转换错误的情况，这点需要特别注意。

4. 树控件数据为什么不显示
   树的数据不显示，一般原因是根节点设置的值问题，默认标准树的根节点值为-1。
   如果排除了根节点原因，还需要进一步排除联动因素。
   还有一种情况是由于加载模式造成的，树的加载方式，当前分为两种：

• 全加载
• 懒加载

全加载会将数据全部放到内存中，组装成树，然后输出，这种方式可以避免很多数据转换的问题，如：树跟列表互相转换时，数据丢失的问题。
但是由于内存资源有限，如果树存在大量节点，全部取出时可能造成内存溢出，所以现在的做法时元数据简单树递归取前5000条树数据，数据视图简单树直接取前10000条列表数据，再组装成树。
那么像数据视图的这种情况，有可能未取到根节点信息，那么最终也就没能构造成树，表现的结果就是数据完全不显示。

5. 解码慢的优化办法
   针对解码较慢的情况，我们一般考虑先由设计人员分析解码SQL，
   尽量让解码时编码和其余查询条件能命中索引，并降低查询复杂度。
   如果解码的数据变更频率较小，建议增加缓存配置，可以减少与数据库的交互。

6. 树的节点为什么都能展开
   树的节点能否展开由是否叶子节点字段的配置决定，如果未配置该字段，且是懒加载的模式，那只能把所有节点识别为枝干节点