### 群友：

”除非提供非常大的便利，才能单独建立一种新的技术体系。“

### 作者：

对，至少要提升 1 倍，才能覆盖 学习成本(约 10%，看文档、跑 Demo 等) + 迁移成本(约 30%，改用新的库 API、工具链、开发流程等) + 风险成本(约 60%，万一不行还得再迁回去重新用以前的方式去做)。

为了对比方便，以下

**APIJSONBoot 指 Spring+SpringBoot+APIJSON，

SSM 指 Spring+SpringBoot+Mybatis(且允许配套 PageHelper 等简化 分页 和简单 CRUD 的插件)，

SSH 指 Spring+SpringBoot+Hibernate/JPA 等 ORM 库，

SSMH 指 SSM + SSH。**

(注：业内 SSM, SSH 通常分别指 Spring+SpringMVC+Mybatis, Spring+Struts+Hibernate，

但 SpringMVC 和 Struts 目前在大部分场景都已被 SpringBoot 包含或取代)

假设表数量为 T， 字段数量为 C，不考虑业务逻辑处理(业务逻辑代码处理基本一致，两者用时相当)，

**APIJSONBoot 在 [适用场景](https://github.com/APIJSON/APIJSON/issues/39#issuecomment-408133096) 的项目中一般都是 20 倍以上的开发效率提升：**

平均 2 分钟配置好一张表的增删改查权限，即可实现各种条件( C! x 每个字段 28 种条件功能 x @combine 与或非 3 种 x 2^C 组合数 的 单表单记录 + 单表多记录 + 结合已配置过权限的其它表各种排列组合 ( T! 个) 总共 C! x 28 x 3 x 2^C x T! 个 细粒度 RESTful 查询接口，

再花 3x1xC 分钟配置增删改校验规则，即可相当于实现了 单表单记录+单表多记录 总共 2xT 个 RESTful 增删改接口，总共用了 2xT + 3xC 分钟开发，然后花最多 5 分钟调热更新接口来热重载配置即可部署生效；

**假设一个开发很熟练地同样实现 APIJSONBoot 总共 2xT + 3xC 分钟实现的各种增删改查功能，用 SSMH 实现 RESTful API，并且还不做任何权限及参数校验，那么**

查询需要 平均每表 30 分钟完成单表不带查询条件的 Controller, Service, Mapper, DTO/VO/BO …，加每个字段 28 个功能 x C， 60 分钟完成一个多表关联查询接口，总共 30xT + 28xCxT + 60x2^T 分钟)，

增删改(假设用了 PageHelper, Mybatis-Plus 等免写 SQL 封装工具) 需要 每张表在写查询接口实现过的 Controller, Service 中新增对应的 3x2 个方法，约 5 分钟，总共 5xT 分钟，然后假设没冲突且不出错的情况下 推送、合并代码，再顺利重启服务部署到开发/测试环境，一般最快也要 10 分钟。

**总结下，只是完成接口开发和自测，不算部署时间，

APIJSONBoot(按慢估计) 相比 SSMH(按快估计) 这种传统方式开发总时间对比为：**

(2xT + 3xCxT) : (30xT + 28xCxT + 60x2^T + 5xT)

简化为：

(2xT + 3xCxT) : (35xT + 28xCxT + 60x2^T)

假设需要对 1 张表(3 个字段)开发接口，即 T = 1, C = 3 ，那么总时间对比为

11 min(约十分钟) : 239 min(3.98 小时，约一上午)，速度提升 20.73 倍！

假设需要对 5 张表(平均每张表 4 个字段)开发接口，即 T = 5，C = 4，那么总时间对比为

70 min(约一小时) : 44.25 hour(朝九晚六 5.53 天，约一星期)，速度提升 36.93 倍！

假设需要对 10 张表(平均每张表 10 个字段)开发接口，即 T = 10，C = 10，那么总时间对比为

320 min(约一上午) : 44.85 day(996 工作 3.45 月，约一季度)，速度提升 200.84 倍！

假设需要对 20 张表开发接口(平均每张表 15 个字段)，即 T = 20，C = 15，那么总时间对比为

940 min(约上班两天) : 1456.57 month(全年无休 11117 工作 239.44 年，接近美国建国至今 243 年！)，速度提升 66,939.06(约 7 万) 倍！

假设需要对 50 张表开发接口(平均每张表 20 个字段)，即 T = 50，C = 20，那么总时间对比为

3100 min(约上班一周) : 128527386625.93 year(时刻工作、一秒不停也要 1285 亿年，超过宇宙年龄 138.2 亿年！)，速度提升 21791611100189(21 万亿) 倍！

**为什么表数量越多，开发总时间差距会指数暴增呢？**

因为 APIJSONBoot 支持任意表关联组合查询，把 SSMH 随表数量指数暴增的 RESTful API 开发时间 降到了线性稳定增长！

**为什么后面 SSMH 开发 20 张表 CRUD 接口的时间需要几百年，50 张表甚至超过宇宙年龄了，实际上也就几个月开发完了啊？**

因为实际上需求并不会覆盖 表的所有 CRUD、 表的所有排列组合、字段的所有条件、字段的所有组合。

因为主要是表排列组合导致了指数暴增，所以我们再根据实际情况，把 表的所有排列组合 减少至常规的 两两 排列组合，

那就只有 T! / (T - 2 )! 种情况，SSMH 开发 RESTful API 的公式变为：

(35xT + 28xCxT + 60xT! / (T - 2 )! )

而 APIJSONBoot 的公式不变，所以对比为：

T = 1 时：11 : 179

T > 1 时：(2xT + 3xCxT) : (35xT + 28xCxT + 60xTx(T - 1) )

简化为：

T = 1 时：11 : 179

T > 1 时：Tx(3xC + 2) : Tx(60xT + 28xC - 25)

**按照一般互联网中小型项目情况可得出以下对比表格：**

表数量 T | 平均每表字段数 C | APIJSONBoot 按慢估计 | SSMH 按快估计 | APIJSONBoot 提速倍数

-------- | --------- | ------------- | -------------- | -----------

1 | 3 | 11 min(约十分钟) | 179 min(约一上午) | 15.27

5 | 4 | 70 min(约一小时) | 1935 min(约朝九晚六一周) | 26.64

10 | 10 | 320 min(约一上午) | 8550 min(大小周超过半个月) | 25.72

20 | 15 | 940 min(约上班两天) | 31900 min(约 996 两个月) | 32.94

50 | 20 | 3100 min(约上班一周) | 176750 min(11117 超过半年) | 56.02

这还是在 APIJSONBoot 实现了权限和参数校验、SSMH 不做权限和参数校验的情况下！

如果 APIJSONBoot 也不做权限和参数校验(全局关闭)，那么根本不用花任何时间，总时长总是 0 ！

表数量T | 平均每表字段数C | APIJSONBoot按慢估计 | SSMH按快估计 | APIJSONBoot提速倍数

APIJSONBoot 对比 SSM/SSH 等开发效率提升 20 倍以上

平均 2 分钟配置好一张表的增删改查权限，即可实现各种条件( C! x 每个字段 28 种条件功能 x @combine 与或非 3 种 x 2^C 组合数 的 单表单记录 + 单表多记录 + 结合已配置过权限的其它表各种排列组合 ( T! 个) 总共 C! x 28 x 3 x 2^C x T! 个 细粒度 RESTful 查询接口，

平均 2 分钟配置好一张表的增删改查权限，即可实现各种条件( C! x 每个字段 28 种条件功能 x @combine 与或非 3 种 x 2^C 组合数 的 单表单记录 + 单表多记录 + 结合已配置过权限的其它表各种排列组合 ( T! 个) 总共 C! x 28 x 3 x 2^C x T! 个 细粒度 RESTful 查询接口，

平均 2 分钟配置好一张表的增删改查权限，即可实现各种条件( C! x 每个字段 28 种条件功能 x \@combine 与或非 3 种 x 2^C 组合数 的 单表单记录 + 单表多记录 + 结合已配置过权限的其它表各种排列组合 ( T! 个) 总共 C! x 28 x 3 x 2^C x T! 个 细粒度 RESTful 查询接口，

再花 3x1xC 分钟配置增删改校验规则，即可相当于实现了 单表单记录+单表多记录 总共 2xT 个 RESTful 增删改接口，总共用了 2xT + 3xC 分钟开发，然后花最多 5 分钟调热更新接口来热重载配置即可部署生效；

SSM 指 Spring+SpringBoot+Mybatis(且允许配套 PageHelper 等简化 分页 和简单 CRUD 的插件)，

为了对比方便，以下

**APIJSONBoot 指 Spring+SpringBoot+APIJSON，

SSM 指 Spring+SpringBoot+Mybatis(且允许配套 PageHelper 等简化 分页 和简单 CRUD 的插件以及生成代码工具)，

SSH 指 Spring+SpringBoot+Hibernate/JPA 等 ORM 库，

SSMH 指 SSM + SSH。**

(注：业内 SSM, SSH 通常分别指 Spring+SpringMVC+Mybatis, Spring+Struts+Hibernate，

但 SpringMVC 和 Struts 目前在大部分场景都已被 SpringBoot 包含或取代)

假设表数量为 T， 字段数量为 C，不考虑业务逻辑处理(业务逻辑代码处理基本一致，两者用时相当)，

**APIJSONBoot 在 [适用场景](https://github.com/APIJSON/APIJSON/issues/39#issuecomment-408133096) 的项目中一般都是 20 倍以上的开发效率提升：**

平均 2 分钟配置好一张表的增删改查权限，即可实现各种条件( C! x 每个字段 28 种条件功能 x @ combine 与或非 3 种 x 2^C 组合数 的 单表单记录 + 单表多记录 + 结合已配置过权限的其它表各种排列组合 ( T! 个) 总共 C! x 28 x 3 x 2^C x T! 个 细粒度 RESTful 查询接口，

再花 3x1xC 分钟配置增删改校验规则，即可相当于实现了 单表单记录+单表多记录 总共 2xT 个 RESTful 增删改接口，总共用了 2xT + 3xC 分钟开发，然后花最多 5 分钟调热更新接口 /reload 来热重载配置即可部署生效；

**假设一个开发很熟练地同样实现 APIJSONBoot 总共 2xT + 3xC 分钟实现的各种增删改查功能，用 SSMH 实现 RESTful API，并且还不做任何权限及参数校验，那么**

查询需要 平均每表 30 分钟完成单表不带查询条件的 Controller, Service, Mapper, DTO/VO/BO …，加每个字段 28 个功能 x C， 60 分钟完成一个多表关联查询接口，总共 30xT + 28xCxT + 60x2^T 分钟)，

增删改(假设用了 PageHelper, Mybatis-Plus 等免写 SQL 封装工具) 需要 每张表在写查询接口实现过的 Controller, Service 中新增对应的 3x2 个方法，约 5 分钟，总共 5xT 分钟，然后假设没冲突且不出错的情况下 推送、合并代码，再顺利重启服务部署到开发/测试环境，一般最快也要 10 分钟。

**总结下，只是完成接口开发和自测，不算部署时间，

APIJSONBoot(按慢估计) 相比 SSMH(按快估计) 这种传统方式开发总时间对比为：**

(2xT + 3xCxT) : (30xT + 28xCxT + 60x2^T + 5xT)

简化为：

(2xT + 3xCxT) : (35xT + 28xCxT + 60x2^T)

假设需要对 1 张表(3 个字段)开发接口，即 T = 1, C = 3 ，那么总时间对比为

11 min(约十分钟) : 239 min(3.98 小时，约一上午)，速度提升 20.73 倍！

假设需要对 5 张表(平均每张表 4 个字段)开发接口，即 T = 5，C = 4，那么总时间对比为

70 min(约一小时) : 44.25 hour(朝九晚六 5.53 天，约一星期)，速度提升 36.93 倍！

假设需要对 10 张表(平均每张表 10 个字段)开发接口，即 T = 10，C = 10，那么总时间对比为

320 min(约一上午) : 44.85 day(996 工作 3.45 月，约一季度)，速度提升 200.84 倍！

假设需要对 20 张表开发接口(平均每张表 15 个字段)，即 T = 20，C = 15，那么总时间对比为

940 min(约上班两天) : 1456.57 month(全年无休 11117 工作 239.44 年，接近美国建国至今 243 年！)，速度提升 66,939.06(约 7 万) 倍！

假设需要对 50 张表开发接口(平均每张表 20 个字段)，即 T = 50，C = 20，那么总时间对比为

3100 min(约上班一周) : 128527386625.93 year(时刻工作、一秒不停也要 1285 亿年，超过宇宙年龄 138.2 亿年！)，速度提升 21791611100189(21 万亿) 倍！

**为什么表数量越多，开发总时间差距会指数暴增呢？**

因为 APIJSONBoot 支持任意表关联组合查询，把 SSMH 随表数量指数暴增的 RESTful API 开发时间 降到了线性稳定增长！

**为什么后面 SSMH 开发 20 张表 CRUD 接口的时间需要几百年，50 张表甚至超过宇宙年龄了，实际上也就几个月开发完了啊？**

因为实际上需求并不会覆盖 表的所有 CRUD、 表的所有排列组合、字段的所有条件、字段的所有组合。

因为主要是表排列组合导致了指数暴增，所以我们再根据实际情况，把 表的所有排列组合 减少至常规的 两两 排列组合，

那就只有 T! / (T - 2 )! 种情况，SSMH 开发 RESTful API 的公式变为：

(35xT + 28xCxT + 60xT! / (T - 2 )! )

而 APIJSONBoot 的公式不变，所以对比为：

T = 1 时：11 : 179

T > 1 时：(2xT + 3xCxT) : (35xT + 28xCxT + 60xTx(T - 1) )

简化为：

T = 1 时：11 : 179

T > 1 时：Tx(3xC + 2) : Tx(60xT + 28xC - 25)

**按照一般互联网中小型项目情况可得出以下对比表格：**

表数量 T | 平均每表字段数 C | APIJSONBoot 按慢估计 | SSMH 按快估计 | APIJSONBoot 提速倍数

-------- | --------- | ------------- | -------------- | -----------

1 | 3 | 11 min(约十分钟) | 179 min(约一上午) | 15.27

5 | 4 | 70 min(约一小时) | 1935 min(约朝九晚六一周) | 26.64

10 | 10 | 320 min(约一上午) | 8550 min(大小周超过半个月) | 25.72

20 | 15 | 940 min(约上班两天) | 31900 min(约 996 两个月) | 32.94

50 | 20 | 3100 min(约上班一周) | 176750 min(11117 超过半年) | 56.02

这还是在 APIJSONBoot 实现了权限和参数校验、SSMH 不做权限和参数校验的情况下！

如果 APIJSONBoot 也不做权限和参数校验(全局关闭)，那么根本不用花任何时间，总时长总是 0 ！