在我的这套方案里，我们是需要对所有的数据源进行管理的，说的简单粗暴点就是：我们存在一个“数据源的管理系统”。
从我们的业务场景中来说，数据源应该是支持多租户的，不同的租户有不同的数据源，某些数据源是针对某个企业特定开发的。但是我认为在这个阶段，这些都不是最重要的东西，所以我的设计只考虑了但用户的场景。
t_datasource
id # 自增主键
name # 数据源的名称全局唯一
type # 取值Get、Post，前端按照该值发送http请求（目前主要为Get，Post用于开发高度自定义）
# 新增一种Fixed，Fixed代表的是由rawData生成的
params # 前端按照该值提供参数，存储为对象数组：[{"paramName":"tmp","paramType":"JString"}]
requestUrl # 前端将请求发送到该地址
returnType # 表单编排器通过该字段判断该数据源能够绑定到某个组件的某个属性声明（系统定义的类型JList、JBoolean、JMap）
t_raw_data
id
name
data
技术需求
- 需要知道Get支不支持向服务器传递复杂的请求体，如果可以的话，type字段可以不用存在（其实不建议删除）。
- params目前也无法描述负载的请求体，实际上，如果params是一个json的话，完全是可以进行描述的，案例如下：
需求的请求体为（即params参数为）：
{
"condition": {
"app": 1,
"timeStart": 2,
"timeEnd": 3
},
"scope": {
"app": "auth-center",
"ownder": "system-admin",
"timeStart": 2,
"timeEnd": 4
}
}
对应的描述可以为：
{
"condition": {
"app": "JInteger",
"timeStart": "JInteger",
"timeEnd": "JInteger"
},
"scope": {
"app": "JString",
"ownder": "JString",
"timeStart": "JInteger",
"timeEnd": "JInteger"
}
}
当用户为某个组件绑定了了该数据源，所呈现的参数配置为：
condition.app
condition.timeStart
condition.timeEnd
scope.app
scope.ownder
scope.timeStart
scope.timeEnd
这部分都是临时设计的，我不确定这样的设计能不能囊括需求。这个只能算作抛砖引玉，到时候看看大家有没有更好的需求吧。这部分的需求，在基础组件的设计与实现过程中应该是不需要的，所以暂时不用太着急。
按照该表结构设计的数据源与实现（针对企业库案例）
数据源管理
- 增、删、改、查
- 检查数据源是否可用
- 查看数据源的数据