一、特殊名词介绍

无

二、常用接口说明

1、数据源和数据集的区别

数据源是数据本身的一种存储介质。而帆软中的数据源连接，是指获得从该介质中提取数据的能力的一种规则或方法的代码实现。

举例：JDBC数据源连接就是，通过指定连接的类型和连接的目标地址，通过用户信息进行授权获得获取目标数据库数据的方法的代码实现。

数据集是指一组用于解释或分析特定业务甚至更细粒度的业务单元的数据的集合。而帆软中的数据集接口，是指获取这样一组数据集合的规则和方法的代码实现。

举例：数据查询，就是从我们定义的介质（JDBC/JNDI数据源）中通过SQL语法获取处理业务需要的数据的代码实现

从定义上来看，数据源连接是获得授权，而数据集是指定数据边界。

2、是否可以使用数据集来直接获得授权？

从技术上来说，完全没有问题。数据集和数据源的划分是架构层面的。在具体的实现上数据集本身是可以直接包含数据源连接的部分的。开发者只需要根据自己面对的场景进行合适的选择即可。

大原则上：1.要让插件的设计、开发、维护变得清晰简单。2.要让用户感觉便捷舒适。即可

一般推荐：

1.如果开发者面对的业务需求中，只有一个“数据源”的，可直接用数据集接口实现即可。【也不绝对，主要还是看使用者的需求，如果使用者觉得需要使用数据源配置更符合使用者的习惯，则按使用者的习惯处理即可】

2.存在登录、认证、鉴权、业务接口选择的场景，一般推荐封装成为数据源的形式。【特例是，如果开发的数据集总共就只建几个数据集的话，就没必要单独封装数据源了】

3.当开发者拿到需求时无法准确的区分数据源和数据集在当前需求中的边界时，可简单粗暴的认为，凡是存在大量数据集共用的配置都可抽离到数据源中配置。凡是用于定义从所有数据中选择哪一部分的配置都划归到数据集中配置。凡是具有一定时效性的非数据缓存相关配置都可以抽离到数据源中配置。且后者优先于前者，剩下的配置怎么放都可以。

3、一个完整的数据源+数据集插件需要完整的实现上面的5个接口么？

如果开发者的目标是上架到商城中销售，那么可以不实现数据源的两个接口，但是数据集的3个接口必须全部实现，否则一律不允许上架。至于数据源的两个接口，则由课题评委会审核，如果评委会认为缺失需要区分数据源的，则必须实现数据源的2个接口（缺一不可）。

如果开发者的目标仅仅是解决某个用户的某个特定的场景，则实现的接口数量没有任何要求，全部取决于所解决的实际场景需要。

4、常见的数据源和数据集设计的几个部分

A.常见数据源在设计上：

界面和配置会分为，动态配置、固定配置、保留参数区域三个部分；

而数据源的“连接”功能在设计上应注意区分，一般分为 连接器、连接配置、凭证实体（其中连接器经常会跟“客户端”混合在一起）。连接配置就是我们界面配置产生的部分，将配置传入连接器中，得到一个授权凭证。后续“客户端”就可以利用凭证连接取数了。

注意：实际取数的逻辑不属于数据源的职能，在设计上开发者应予以区分，最常见的手段就是封装统一的中间层“客户端”。

B.常见的数据集在设计上：

界面配置上，根据有无数据源决定我们是否需要选择数据源。其他的部分基本都是固定的 参数区域 和 约束规则区域。

约束规则也分两种

一种是数据提供者给定的规范，即数据源头确定的数据允许划分的最小边界颗粒度（比如通过接口，通过过滤参数等等的）

一种是程序拿到数据后进行二次加工通过过滤和聚合得到的满足业务要求需要的数据边界最小颗粒度（比如二次汇总，关键字筛选、排序等等操作）

根据约束规则的划分，一般在实现上把取数的过程分为4个部分

1.取数前准备；这个过程中主要做上下文环境的换算，处理配置信息，获取授权

2.实际取数；这个过程就是我们使用准备好的配置信息，实际从介质中抽取数据到本地的过程

3.取数二次约束；这个过程主要是对抽取到本地的数据根据约束信息进行二次加工处理

4.数据转换；程序从介质中取到的数据结构上并不一定跟帆软的要求一致，那么需要程序对数据的结构进行转换。转换成二维表的形式才能变成帆软产品中可以直接使用的数据。

当开发者拿到一个完整的取数需求时，首先要做的就是分解需求。判断是否需要划分出数据源的操作。然后再根据上面的常见设计的几个部分的划分，来套需求的细节，基本上所有的取数需求都可以使用这套模式套用。

具体的每个接口的使用在每个接口的文档和demo中都有详细的说明和示例，这里就不再赘述。取数开发中的一些常用技巧会在后续的专题文章中单独介绍。

三、开源案例

免责声明：所有文档中的开源示例，均为开发者自行开发并提供。仅用于参考和学习使用，开发者和官方均无义务对开源案例所涉及的所有成果进行教学和指导。若作为商用一切后果责任由使用者自行承担。

无