登录
注册
开源
企业版
高校版
搜索
帮助中心
使用条款
关于我们
开源
企业版
高校版
私有云
模力方舟
AI 队友
登录
注册
轻量养虾,开箱即用!低 Token + 稳定算力,Gitee & 模力方舟联合出品的 PocketClaw 正式开售!点击了解详情
代码拉取完成,页面将自动刷新
开源项目
>
WEB应用开发
>
Web开发框架
&&
捐赠
捐赠前请先登录
取消
前往登录
扫描微信二维码支付
取消
支付完成
支付提示
将跳转至支付宝完成支付
确定
取消
Watch
不关注
关注所有动态
仅关注版本发行动态
关注但不提醒动态
843
Star
6.6K
Fork
1.5K
GVP
腾讯开源
/
APIJSON
代码
Issues
66
Pull Requests
2
Wiki
统计
流水线
服务
JavaDoc
质量分析
Jenkins for Gitee
腾讯云托管
腾讯云 Serverless
悬镜安全
阿里云 SAE
Codeblitz
SBOM
开发画像分析
我知道了,不再自动展开
更新失败,请稍后重试!
移除标识
内容风险标识
本任务被
标识为内容中包含有代码安全 Bug 、隐私泄露等敏感信息,仓库外成员不可访问
APIJSONBoot 对比 SSM/SSH 等开发效率可提升 20 倍以上
置顶
待办的
#I2AGSY
TommyLemon
拥有者
创建于
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 !
评论 (
21
)
登录
后才可以发表评论
状态
待办的
待办的
进行中
已完成
已关闭
负责人
未设置
标签
未设置
标签管理
里程碑
未关联里程碑
未关联里程碑
Pull Requests
未关联
未关联
关联的 Pull Requests 被合并后可能会关闭此 issue
分支
未关联
分支 (
-
)
标签 (
-
)
开始日期   -   截止日期
-
置顶选项
不置顶
置顶等级:高
置顶等级:中
置顶等级:低
优先级
不指定
严重
主要
次要
不重要
参与者(9)
Java
1
https://gitee.com/Tencent/APIJSON.git
git@gitee.com:Tencent/APIJSON.git
Tencent
APIJSON
APIJSON
点此查找更多帮助
搜索帮助
Git 命令在线学习
如何在 Gitee 导入 GitHub 仓库
Git 仓库基础操作
企业版和社区版功能对比
SSH 公钥设置
如何处理代码冲突
仓库体积过大,如何减小?
如何找回被删除的仓库数据
Gitee 产品配额说明
GitHub仓库快速导入Gitee及同步更新
什么是 Release(发行版)
将 PHP 项目自动发布到 packagist.org
仓库举报
回到顶部
登录提示
该操作需登录 Gitee 帐号,请先登录后再操作。
立即登录
没有帐号,去注册