Sign in
Sign up
Explore
Enterprise
Education
Search
Help
Terms of use
About Us
Explore
Enterprise
Education
Gitee Premium
Gitee AI
AI teammates
Sign in
Sign up
Fetch the repository succeeded.
Open Source
>
Web Development
>
Web Framework
&&
Donate
Please sign in before you donate.
Cancel
Sign in
Scan WeChat QR to Pay
Cancel
Complete
Prompt
Switch to Alipay.
OK
Cancel
Watch
Unwatch
Watching
Releases Only
Ignoring
842
Star
6.6K
Fork
1.5K
GVP
腾讯开源
/
APIJSON
Code
Issues
66
Pull Requests
2
Wiki
Insights
Pipelines
Service
JavaDoc
Quality Analysis
Jenkins for Gitee
Tencent CloudBase
Tencent Cloud Serverless
悬镜安全
Aliyun SAE
Codeblitz
SBOM
Don’t show this again
Update failed. Please try again later!
Remove this flag
Content Risk Flag
This task is identified by
as the content contains sensitive information such as code security bugs, privacy leaks, etc., so it is only accessible to contributors of this repository.
APIJSONBoot 对比 SSM/SSH 等开发效率可提升 20 倍以上
Top
Backlog
#I2AGSY
TommyLemon
owner
Opened this issue
2020-12-22 23:03
### 群友: ”除非提供非常大的便利,才能单独建立一种新的技术体系。“ ### 作者: 对,至少要提升 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 分钟调热更新接口 /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 !
### 群友: ”除非提供非常大的便利,才能单独建立一种新的技术体系。“ ### 作者: 对,至少要提升 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 分钟调热更新接口 /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 !
Comments (
21
)
Sign in
to comment
Status
Backlog
Backlog
Doing
Done
Closed
Assignees
Not set
Labels
Not set
Label settings
Milestones
No related milestones
No related milestones
Pull Requests
None yet
None yet
Successfully merging a pull request will close this issue.
Branches
No related branch
Branches (
-
)
Tags (
-
)
Planed to start   -   Planed to end
-
Top level
Not Top
Top Level: High
Top Level: Medium
Top Level: Low
Priority
Not specified
Serious
Main
Secondary
Unimportant
参与者(9)
Java
1
https://gitee.com/Tencent/APIJSON.git
git@gitee.com:Tencent/APIJSON.git
Tencent
APIJSON
APIJSON
Going to Help Center
Search
Git 命令在线学习
如何在 Gitee 导入 GitHub 仓库
Git 仓库基础操作
企业版和社区版功能对比
SSH 公钥设置
如何处理代码冲突
仓库体积过大,如何减小?
如何找回被删除的仓库数据
Gitee 产品配额说明
GitHub仓库快速导入Gitee及同步更新
什么是 Release(发行版)
将 PHP 项目自动发布到 packagist.org
Repository Report
Back to the top
Login prompt
This operation requires login to the code cloud account. Please log in before operating.
Go to login
No account. Register