技术改变世界,前后协同变革 自动化 ORM 可靠度高达 99.85%
TommyLemon · TommyLemon · 2019-05-29 09:33:59 +08:00 · 25980 次点击这是一个创建于 2041 天前的主题，其中的信息可能已经有所发展或是发生改变。
APIJSON 3.5.0-3.5.7 更新内容:
-
新增存储过程 @key():"fun(...)"，用法基本和远程函数 key():"fun(...)" 一样；
-
新增性能分析 @explain 和缓存设置 @cache 两个对象关键词；
-
新增最大 对象数量、数组数量、嵌套层级等方法，限制请求、过载保护；
-
新增 PgClass 和 PgAttribute 查 PostgreSQL 的表属性和字段属性;
-
LEFT JOIN 和 RIGHT JOIN 支持定制子查询外层的 column,group,order,having ；
-
多方面提升性能；完善和解决 bug 等；代码、文档等其它优化。
具体见 Release 发布版本。
APIJSON 简介
APIJSON 是一种为 API 而生的 JSON 网络传输协议。
为 简单的增删改查、复杂的查询、简单的事务操作 提供了完全自动化的 API。
能大幅降低开发和沟通成本，简化开发流程，缩短开发周期。
适合中小型前后端分离的项目，尤其是互联网创业项目和企业自用项目。
多表关联查询、结构自由组合、多个测试账号、一键共享测试用例
自动生成封装请求 JSON 的 Android 与 iOS 代码、一键下载自动生成的 JavaBean
自动保存请求记录、自动生成接口文档，可添加常用请求、快捷查看一键恢复
一键自动接口回归测试，不需要写任何代码(注解、注释等全都不要)
第三方机构对 APIJSON 的代码扫描，测试结果可靠性高达 99.85%
APIJSON 用 SpringBoot 提供了自动化 API，
自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入，
提供自动化的各种 JOIN(INNER, LEFT, RIGHT 等)，
还支持多字段排序 order by，多字段分组 group by，聚合函数 having
等几乎所有 MySQL,PostgreSQL,Oracle 的常规功能。
通过自动化 API，前端可以定制任何数据、任何结构！
大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！
前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！
后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！
在线解析
-
自动生成接口文档，清晰可读永远最新
-
自动校验与格式化，支持高亮和收展
-
自动生成各种语言代码，一键下载
-
自动管理与测试接口用例，一键共享
-
自动给请求 JSON 加注释，一键切换
对于前端
-
不用再向后端催接口、求文档
-
数据和结构完全定制，要啥有啥
-
看请求知结果，所求即所得
-
可一次获取任何数据、任何结构
-
能去除重复数据，节省流量提高速度
对于后端
-
提供通用接口，大部分 API 不用再写
-
自动生成文档，不用再编写和维护
-
自动校验权限、自动管理版本、自动防 SQL 注入
-
开放 API 无需划分版本，始终保持兼容
-
支持增删改查、模糊搜索、正则匹配、远程函数等
🏆码云最有价值开源项目 🚀后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
创作不易，GitHub 右上角点 ⭐Star 支持下吧，谢谢^_^
第 1 条附言 · 2019-05-29 15:58:41 +08:00
关于后端自定义的业务逻辑处理，我已经在文档、评论、Issue 里写了很多了，
可以提供 远程函数 或者 重写相关方法，大家还可以看看网友写的文章，
文中强调了 APIJSON 使用很灵活，重写一些方法就能自定义处理。
APIJSON 自动化接口和文档的快速开发神器 （一）
https://blog.csdn.net/qq_41829492/article/details/88670940
可以提供 远程函数 或者 重写相关方法，大家还可以看看网友写的文章，
文中强调了 APIJSON 使用很灵活，重写一些方法就能自定义处理。
APIJSON 自动化接口和文档的快速开发神器 （一）
https://blog.csdn.net/qq_41829492/article/details/88670940
第 2 条附言 · 2019-05-29 16:21:31 +08:00
APIJSON 生态内其它项目
APIJSONAuto 自动化接口管理工具，自动生成文档与注释、自动生成代码、自动化回归测试、自动静态检查等
APIJSON.NET C# 版 APIJSON ，支持 MySQL, PostgreSQL, MS SQL Server, Oracle, SQLite
apijson-php PHP 版 APIJSON，基于 ThinkPHP，支持 MySQL, PostgreSQL, MS SQL Server, Oracle 等
apijson Node.ts 版 APIJSON，支持 MySQL, PostgreSQL, MS SQL Server, Oracle, SQLite, MariaDB, WebSQL
uliweb-apijson Python 版 APIJSON，支持 MySQL, PostgreSQL, MS SQL Server, Oracle, SQLite 等
APIJSON Go 版 APIJSON，功能开发中...
APIJSONKOTLIN Kotlin 版 APIJSON，基础框架搭建中...
APIJSONParser 第三方 APIJSON 解析器，将 JSON 动态解析成 SQL
ApiJsonByJFinal 整合 APIJSON 和 JFinal 的 Demo
SpringServer1.2-APIJSON 智慧党建服务器端，提供 上传 和 下载 文件的接口
APIJSON-Android-RxJava 仿微信朋友圈动态实战项目，ZBLibrary(UI) + APIJSON(HTTP) + RxJava(Data)
Android-ZBLibrary Android MVP快速开发框架，Demo全面，注释详细，使用简单，代码严谨
感谢热心的作者们的贡献，点 ⭐Star 支持下他们吧。
第 3 条附言 · 2019-05-30 12:05:59 +08:00
以上是各种语言的 APIJSON 后端库（基本每个都有 Demo，部分有比较详细的文档）， 主项目提供： 设计规范（CRUD 请求格式；数组、搜索、JOIN、子查询、性能分析 等各种查询功能，都有 Demo 点击测试）， Java 的 ORM 库 APIJSONORM（实现 JSON 对象 -> SQL -> 封装 JSON 返回结果 + 权限、数据、结构校验）， Java 的 后端 Demo（APIJSONBoot: SpringBoot, APIJSONFinal: JFinal, APIJSONOracle: Oracle）。
还提供了： Android 客户端 Demo (APIJSONApp + APIJSONTest 两个工程), iOS 客户端 Demo (Swift) , JavaScript 网页前端 Demo(原生+Vue) ， Python 的 Demo（可用于 爬数据 调用 Java 或其它 Server 的 API 来持久化存取）。
每个工程根目录都有一个 README.md 展示快速上手的文档。 首页还提供现成的 APIJSONApp.apk, APIJSONTest.apk 下载， 视频教程、在线测试工具、English Document 入口。
https://i.v2ex.co/T272D2Xd.jpeg 还有 已登记使用的 企业或项目、贡献者们、生态内其它项目、推荐博客、码云链接 等等。
 |
101
ianva 2019-05-30 10:42:07 +08:00
都 GraphQL 的年代了做这个
|
 |
102
tt67wq 2019-05-30 10:49:51 +08:00
有没有被注入的风险？
|
 |
103
glfpes 2019-05-30 11:02:13 +08:00
老实说，现在看到面试者提到 github 的 star 等数据，已经不作为参考了。
|
 |
105
TommyLemon OP |
|
107
TommyLemon OP @yixiang @KickAssTonight @peyppicp @tt67wq
APIJSON 提供自动化权限管理、自动化数据和结构校验、自动限流防止过载、自动防 SQL 注入 https://github.com/APIJSON/APIJSON/issues/14 关于字段级访问控制见这个 issue https://github.com/APIJSON/APIJSON/issues/31 |
 |
108
wangyongbo 2019-05-30 11:50:13 +08:00
虽然我不用 java， 但是我还是表示支持。 某些场景 很合适。
|
|
109
TommyLemon OP @ianva 是有些类似，很多人没搞清楚总是说“比你的 APIJSON 强”，“完爆 APIJSON ”之类的。
事实上 Facebook 的 GraphQL 是 Gateway，而 APIJSON 是 ORM，有着本质上的区别， 真要放一般的互联网项目开发中拿来对比，那就是 APIJSON “完爆” GraphQL 了。 https://juejin.im/post/5ae80edd51882567277433cf |
|
110
TommyLemon OP @wangyongbo
Node, Python, PHP, Java, C#, Go 语言的 APIJSON 后端库， Android, iOS, JavaScript(原生+Vue) 的前端 Demo 都有的 https://github.com/TommyLemon/APIJSON |
|
111
TommyLemon OP @wangxiaoaer
1 ）项目文档差 你去找找 5 - 7K Star 的项目对比下，有提供这么全的 Demo， 这么详细的注释、这么严谨详细的文档、多个视频教程、强大易用的在线测试工具 的 Java 项目，发出来看看有几个。 2 ）摆不正自己的位置 不管是项目主页，这篇帖子，还是评论里的回复，都不知道说了多少遍了： APIJSON 是一种为 API 而生的 JSON 网络传输协议。 为 简单的增删改查、复杂的查询、简单的事务操作 提供了完全自动化的 API。 能大幅降低开发和沟通成本，简化开发流程，缩短开发周期。 适合中小型前后端分离的项目，尤其是互联网创业项目和企业自用项目。 应用场景还不够清楚？什么叫摆不正自己的位置？ 3 ）推广手段 GitHub 马太效应，不推广，会死。 Star，issue，群里提问，第三方的博客 本身就是对 APIJSON 的不同形式的认可。 |
|
112
TommyLemon OP @skadi 圈子就这么点大，见到几次不是很正常？其它人一两周发一次帖推广的你都没印象？我一个月一次就不特殊对待了？
|
|
113
TommyLemon OP @Ehco1996 默认每次请求都有自带的内存 cache，可重写 putCache，removeCache 方法自定义 Redis 等实现
|
|
114
TommyLemon OP @guoyang APIJSON 核心是一个 ORM 库，建表、维护表（索引等）不属于它的范围。
APIJSON 字段限制(可选)、查询缓存、查询预判、索引前置 等做了多方面性能优化 https://github.com/APIJSON/APIJSON/issues/16/ 上亿记录的表，就不要指望 ORM 在复杂查询下能帮你自动优化得很好了， 可以做分表分库（可配合用 MyCat，ShardingJDBC 等中间件），或者用 TiDB 等分布式数据库 |
|
115
TommyLemon OP |
|
116
TommyLemon OP @gccdchen 感谢在 文档、引入 等优化的反馈和建议
|
|
117
TommyLemon OP |
|
118
TommyLemon OP @hlwjia “整天挂在嘴边”？
“技术改变世界，前后协同变革” 是我在公司内开分享会时的一个 Slogan， 最上面的图片是分享会的 PPT 主题页，还加了日期时间打印出了邀请函。 公司总经理还说标语很好，建议 “前后协同变革” 改为 “协同驱动变革”。 |
|
119
TommyLemon OP @sxw11
Java 开发工程师用 Java 写的 ORM 库，你说是前端就是前端了？ 哪里说了后端只有 CRUD ？ APIJSON 通过自动化 API 实现 [大部分] CRUD 的业务需求， 但还有部分需要特殊处理数据或结构的地方做不了自动化， 所以 APIJSON 提供了 [远程函数]，后端可以在里面写代码自定义自己的业务逻辑。 https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2 还有一小部分 很复杂的查询(一般对应报表之类的需求，各种 JOIN 和子查询 嵌套、字符串拼接 等，SQL 写一屏以上)、 复杂的事务操作(操作多表，还可能中间 CRUD 出现两种以上，各种校验、多次读写、事务回滚、定制异常等) 等用 APIJSON 做就很吃力了甚至不能实现，建议还是用手写接口(包括 SQL)的方式来实现。 还有后端也不止 CRUD，还有各种 报表统计、数据分析、个性化推荐、服务监控、数据库运维(如果没有 DBA 的话) 等工作，这些也不是 APIJSON 的适用范围或者说应用场景。 |
 |
120
yinzhili 2019-05-30 12:52:32 +08:00
思路很不错。但是代码风格不像是长期做后端的程序员的习惯，有点随意。恐怕使用者会担忧可能存在的 bug 以及日后维护的难度。
|
 |
121
omph 2019-05-30 13:26:38 +08:00
|
 |
122
likaka 2019-05-30 15:04:54 +08:00
重复造轮子
|
|
123
TommyLemon OP @yinzhili 请问你说的是哪个工程的代码？
如果是 APIJSON-Java-Server，已经有人测试过，可靠度 99.85% https://github.com/APIJSON/APIJSON/issues/48 至于代码风格，主观感受各不一样，我们可以对照下阿里的 P3C Java 规范哦 https://github.com/alibaba/p3c |
|
124
TommyLemon OP @likaka 麻烦把类似的轮子发出来对比下，不要空口无凭谢谢
|
 |
125
Huelse 2019-05-30 15:14:39 +08:00  1
已 Start，且不论质量如何，楼主敢在 v2 发想必就已经做好了被挑刺的准备
|
|
126
TommyLemon OP @ianva
@tt67wq @MissThee @lijingyu68 @deadEgg @wangxiaoaer APIJSON 在安全上做了大量的自动防护和优化。 自动校验权限、结构、内容，自动限流过载保护， 自动防 SQL 注入，自动防误删误改数据。 https://github.com/APIJSON/APIJSON/issues/14/ 攻击 GraphQL 的手段可多了 max.book118.com/html/2018/0919/5102220134001314.shtm 欢迎大家也在 APIJSON 上试试，成功了给 APIJSON 发个 issue： APIJSON 源码，项目环境，攻击方式 /源码 APIJSON 全方面对比开源社区影响力前 3 的明星公司 “ Facebook ” 开发的 GraphQL： 基础功能、权限控制、表关联查询 https://github.com/APIJSON/APIJSON/issues/63/ |
|
127
TommyLemon OP @TommyLemon 这几个方面 APIJSON “完爆” GraphQL，不服来辩，show me your evidence
|
|
128
TommyLemon OP  |
|
129
TommyLemon OP @Huelse 感谢支持
|
|
130
TommyLemon OP 很多压根就没仔细看过 文档 /Demo/视频 /源码，凭主观感受胡乱评价，凭空歪曲事实。还有人身攻击的(可见素质之低)
|
 |
131
yun33133 2019-05-30 15:52:55 +08:00
V 站喷子一大堆，敢在 V 站发项目，勇气可嘉啊。不过这套东西还是很不错的，对中小公司来说
|
 |
132
Feedline 2019-05-30 15:58:17 +08:00
感觉适用性不强，毕竟为了 CURD 而引入一个包，我个人是不太乐意的。希望楼主加油吧。
|
|
133
TommyLemon OP @yun33133 唉，是啊，还有很多人自己没有判断力，也不去验证，人云亦云，被这帮人误导了
|
|
134
TommyLemon OP @Feedline ORM 适用场景还是很广泛的，至于具体到你的项目，那就具体分析了，不适合的场景也不建议使用
|
|
135
TommyLemon OP @Feedline APIJSON 的核心是基于 APIJSON 协议开发的后端 ORM 库 APIJSONORM，对数据库全自动 CRUD，
它只有 49 个 Java 类（ 4 个 package_info.java 可有可无就不算了），只依赖 fastjson 一个库，非常轻量。 https://github.com/APIJSON/APIJSON/tree/master/APIJSON-Java-Server 打包出来的 apijson-orm-3.5.7.jar 只有 254 KB，且它里面没有 fastjson 的源码，也就不会冲突， 在你自己的工程里用 Maven(pom.xml)/Gradle(build.gradle) 或直接 jar /工程 等方式依赖 fastjson 即可。 https://github.com/APIJSON/APIJSON/tree/master/APIJSON-Java-Server/APIJSONBoot/libs |
 |
136
fghjghf 2019-05-30 17:07:16 +08:00
先不说别的暴不暴露了，那 protobuf 呢，或者其他协议格式呢？
|
 |
137
kiinlam 2019-05-30 17:09:34 +08:00
说几句实际场景会遇到的：
1、看着有点类似 graphQL，我试用过 graphQL，发现一旦涉及复杂查询，比如多层嵌套，请求等待时间会很久，可以做缓存，但命中率得看前端发起的查询是否不变，所以性能方面还是很担忧的，不知道你这套方案在性能方面有没有相关评测？ 2、需求变化或后端擦屁股问题。很多企业，特别是中小企业，追求一个字：快。美曰其名“敏捷开发”。然后经常改需求，今天刚上线，产品经理就来了，要改东西，或者 bug 来了，要修复。很多时候，问题只涉及到接口数据问题，通常是找后端做适配。但如果改用前端来主导查询内容，前端网页还好，改下请求内容，重新部署，就搞定了，客户端可就悲剧了，要重新发包，上新版本，这种情况怎么办。 |
 |
138
beidounanxizi 2019-05-30 17:23:21 +08:00 1
@TommyLemon 看老哥这么认真回喷 我认为对自己做的项目还是有成就感的 这点足以 项目本身质量不做评价
|
 |
139
stillyu 2019-05-30 18:12:32 +08:00 via iPhone
我自己的后端框架，建好表了就会自动生成简单的增删改查的控制器，包括分页，关键词查询等。这样就不需要你这个了。
|
 |
140
wanzy 2019-05-30 19:26:08 +08:00 via iPhone
求求你别刷了
|
 |
141
echisan 2019-05-30 19:37:20 +08:00 via iPhone
居然置顶了
|
 |
142
jc89898 2019-05-30 20:04:54 +08:00
有必要吗，跟传销似的，还付费置顶。。。开源项目写得好就会有人关注啊，你这样算啥。。
|
 |
143
54skyer 2019-05-30 20:12:41 +08:00 1
其实看功能挺可以的 PHP 版本的到时候可以考虑下 现在大家都发现了 装 B 或者说不负责任的话 代价是如此的小 而且根本很多人没有用过 认识过 上来就一顿贬低 讽刺 说了多少遍 举证举证!
|
 |
144
mmdsun 2019-05-30 20:41:02 +08:00 via Android
@TommyLemon
表示很感兴趣，但是我没看太明白。简单来说是根据前端传的参数，生成 sql 然后返回 json 给页面？我理解的对吗 如果返回数据像密码需要显示*星号这个可以实现吗？ 与老项目对接怎么样呢？比如有老项目是 spring boot 写的，controller 里面还有不少判断逻辑，应该怎么集成呢？ |
|
145
TommyLemon OP @mmdsun 对的，基本原理就是这样
https://github.com/APIJSON/APIJSON/issues/38 后端重写相关的方法即可，DemoSQLExecutor.onPutColumn 判断 table 和 column，把密码字段的值 改成 * 星号。 不需要管原来各个 API 的的各种判断逻辑哦，加上 7 个自动化 API，直接 return new DemoParser(RequestMethod.GET).parse(request) 即可，如果有统一的权限控制（ session/cookie/jwt 等），在调用前判断即可。 |
|
146
TommyLemon OP @stillyu 这种生成静态代码的工具很多了，但都有几个很大的缺陷：
1.只能生成基本的简单增删改查，有 复杂嵌套、JOIN，子查询 等就不行了。 2.很多时候不能满足需求，还得在生成的代码上改，才能满足 GROUP BY、count(*) 等需求。 3.接口改过后有了不少逻辑，需求改了，用新生成的接口去替换成本很高，还不如在旧接口上改。 APIJSON 是对每次请求动态生成 SQL，需求变了就改请求，调用后就会自动生成新的 SQL， 这样就不用改后端代码，大部分情况下总是能满足各种定制性的需求。 https://raw.githubusercontent.com/TommyLemon/StaticResources/master/APIJSON/Share/Process.png @kiinlam 说的 “需求变化或后端擦屁股问题” 正是 GraphQL 和传统 RESTful 等方式的问题， APIJSON 恰好能很好地解决，大部分情况下总是不改后端代码就能满足需求。 APIJSON 怎么做复杂请求？ https://www.zhihu.com/question/61648519 你们可以在 APIJSONAuto 自动化接口管理工具上试试，任意调整数据和结构， 只要 请求符合 APIJSON 的协议、数据库有对应的表和字段、有权限访问表和字段 就能自动化支持。 请求 JSON 最外层加 "@explain": true 就能查看每个对象内自动生成的 SQL。 http://apijson.org/ |
|
147
TommyLemon OP @kiinlam APIJSON 提供了自动化 JOIN （ LEFT, RIGHT, INNER 等 SQL JOIN 和 应用层连表 APP JOIN ）来优化性能
数组关键词 ④ "join":"&/Table0/key0@,</Table1/key1@" 多表连接方式： "<" - LEFT JOIN ">" - RIGHT JOIN "&" - INNER JOIN "|" - FULL JOIN "!" - OUTTER JOIN "@" - APP JOIN 其中 @ APP JOIN 为应用层连表，会从已查出的主表里取得所有副表 key@ 关联的主表内的 refKey 作为一个数组 refKeys: [value0, value1...]，然后把原来副表 count 次查询 key=$refKey 的 SQL 用 key IN($refKeys) 的方式合并为一条 SQL 来优化性能； 其它 JOIN 都是 SQL JOIN，具体功能和 MySQL,PostgreSQL 等数据库的 JOIN 一一对应， "ViceTable":{ "key@:".../MainTable/refKey" } 会对应生成 MainTable ... JOIN ViceTable ON ViceTable.key=MainTable.refKey。 再强调一下 APIJSON 不生成任何静态代码，只生成动态的 SQL 语句， 前端改了 JSON 参数，后端就生成新的 SQL 语句， 满足新的需求， 不需要后端写任何代码来实现上面的说 模糊搜索、分组排序 等， 还有自动化 JOIN 也不需要后端写代码： ```js { "[]": { "count": 10, // LIMIT 10 "join": "</User/id@", // Comment LEFT JOIN User "Comment": { "content~": "a", // content REGEXP 'a' "@group": "momentId", //GROUP BY momentId "@order": "date+" //ORDER BY date ASC }, "User": { "@column":"id,name", // SELECT id,name "id@": "/Comment/userId" // ON User.id = Comment.userId } } } ``` APIJSONLibrary 生成 ```sql SELECT `Comment`.*, `User`.`id`, `User`.`name` FROM `sys`.`Comment` AS `Comment` WHERE `Comment`.`content` REGEXP 'a' LEFT JOIN (SELECT `id`, `name` FROM `sys`.`apijson_user`) AS `User` ON `User`.`id` = `Comment`.`userId` GROUP BY `Comment`.`momentId` ORDER BY `Comment`.`date` ASC LIMIT 10 OFFSET 0 ``` https://github.com/APIJSON/APIJSON/blob/master/Document.md#3.2 还有 字段限制(可选)、查询缓存、查询预判、性能分析、过载保护 等多方面的优化 https://github.com/APIJSON/APIJSON/issues/16 |
|
148
TommyLemon OP @fghjghf Protobuff, Thrift, Dubbo 等 RPC 协议主要不是为了方便，而是为了传输性能而生的，
虽然能生成一些接口实现与调用的代码，但并没有像 HTTP API 那样有成熟完善文档工具， 所以一般更适合内部使用，尤其是微服务间互相调用，对于前后端分离的项目，联调反而更麻烦。 |
 |
149
IvanLi127 2019-05-30 22:54:26 +08:00 via Android
项目好不好不知道，你这广告看上去十分令人不爽啊。。。
|
|
150
TommyLemon OP v2ex 上要等被喷得差不多了才会有理性的发言
|
 |
151
dk7952638 2019-05-31 08:39:34 +08:00 1
我觉得项目蛮好的，那些说风凉话的，什么 star 没有参考价值的，你自己倒是写出一个来，自己十行代码八个 bug，对别人的代码倒是挑肥拣瘦，真是柠檬
|
|
152
tt67wq 2019-05-31 09:28:02 +08:00 1
厉害
|
 |
153
ddup 2019-05-31 09:31:54 +08:00 via Android 1
不错的项目，看到好些人没仔细看明白就喷，来顶一下楼主
|
 |
155
mougua 2019-05-31 09:36:04 +08:00
项目蛮好的，值得一试。但这宣传风格和舌战群儒的架势。。。呃
|
 |
156
jokerlee 2019-05-31 10:16:00 +08:00 via Android
几年前做过类似的框架。直接 nodejs mongoose mongodb，这种场景下没必要用关系型数据库。从前到后全程是 json 根本不用映射
|
|
157
TommyLemon OP |
 |
158
jowan 2019-05-31 10:42:11 +08:00
喷子无处不在 V 站也不例外
不过回复那些无脑喷的方式你可能处理的不太好 大部分人喷的应该是你对那些喷子的反击方式吧 比如 #23 你这种点评飞机需要造飞机的观点 就比较不合适 无视或者理性回复那些东西 用户对你的项目会更有好感 |
 |
159
ksssdh123 2019-05-31 10:49:48 +08:00
很早就关注过你这个项目了 当时一直在寻找前后端 协同工具，传统的 restful 接口 对于现在是不太适用了
GraphQL 用过 ，你这个也用过，但都是简单的 demo 试用 希望有相关权威能站出来，说说两个的优劣势吧 |
|
160
TommyLemon OP |
|
161
TommyLemon OP @jowan
主要是那个网友不仅没有实际的依据张口就来（“普及率不用实际案例来说明，用的是 github 星星比 hibernate 多”），还人身攻击（“开源界的罗永浩”），所以忍不住这样说了。 而且免费提供的东西，本来就不像顾客买东西那样可以理所当然地批评（付费享受服务）。 “本软件没有授予用户一边免费辱骂一边免费使用的权利、如不同意请不要使用本软件。” 不过如果确实有理有据，我还是会认真对待的，有则改之无则加勉。 坚持一个开源项目需要投入很多的时间精力， 持续维护迭代，反复修改完善文档，回答各种问题， 应对各种质疑、否定、甚至谩骂，也的确需要很大的勇气， 这个项目从 2016 年 11 月开源到现在两年半左右了， 也收获了不少开发者、企业 以及开源中国的认可，还是很欣慰的， 我们会继续坚持帮助大家提升开发效率，减少前后端同事的沟通问题。 |
|
162
TommyLemon OP |
|
163
TommyLemon OP @jokerlee 都不用关系型数据库了，那就没必要用 APIJSON （ MySQL, PostgreSQL, Oracle, TiDB ）了
|
|
164
yinzhili 2019-05-31 11:25:09 +08:00
@TommyLemon 比如你的 ORM 模块，注解、枚举、工具类等都混在一起放在一个 package 下面。再比如你的 Log 的实现也很非主流，日志级别如何修改，日志文件切分要如何做，我没看出来。
|
 |
165
razertory 2019-05-31 11:52:22 +08:00
GraphQL 本身是 BFF (Backend for Frontend) 说是 Gateway 也没毛病，
APIJSON 是自动把前端请求转换成 SQL 的工具，说 ORM 有点过了，适用于直接打在关系型数据库上的应用。 |
 |
166
anakinsky 2019-05-31 13:36:37 +08:00
都已经上了码云 gvp 了，没必要这么极力推广了吧，好不好用用过的人自然帮着推广
|
 |
167
radiolover 2019-05-31 14:43:05 +08:00
楼主国内的资源有多紧缺、竞争有多激烈，你难道不感受不到么？不要像个小白一样看不惯撕逼，撕逼和谩骂本身就是一种生活方式。另外在红海领域，成功绝不仅仅靠的是项目的技术水平。
|
 |
168
Ritr 2019-05-31 17:51:31 +08:00
能做出来，很厉害了。对于中小型项目来说基本就够用了，极大的降低了开发成本
|
 |
169
fleam 2019-05-31 18:52:15 +08:00 via Android
前端不懂 sql，多几个关联查询，数据量一大，数据库死了怎么办。。。
|
|
170
TommyLemon OP 1
@fleam 提供自动化的对象数量，数组数量，最大层级，SQL 执行数量 的查询限制，可重写方法自定义
|
|
171
TommyLemon OP @fleam 后端上传请求 URL 和 JSON 参数给前端用的，SQL 太多或者执行时间太长由后端优化，再给前端
|
|
172
TommyLemon OP @razertory
Hibernate: POJO 对象 > SQL > POJO 对象 APIJSON : JSON 对象 > SQL > JSON 对象 ORM 对象关系映射 这方面来讲并没有本质区别， 说 APIJSON 是 ORM 库怎么就过了？ 再说 TypeORM，Sequelize 等一堆 ORM 不也是用 JSON 对象？ |
|
173
TommyLemon OP @Ritr 感谢认真了解 APIJSON 并给予支持 ^_^
|
|
174
TommyLemon OP @anakinsky 码云首页展示 GVP 项目只有一个月左右，
再说 GVP 在开源中国上发帖要求用码云链接 |
 |
175
my8100 2019-05-31 21:14:51 +08:00 via iPhone
请问如何执行自动化测试，目前代码覆盖率如何，可以在哪看？
|
|
176
TommyLemon OP |
|
177
TommyLemon OP  |
|
178
my8100 2019-06-01 10:29:43 +08:00 via iPhone
请问代码覆盖率有多高呢？
|
|
179
TommyLemon OP @razertory 有个热心的用户觉得 APIJSONORM 里的自动化权限、数据、结构校验可以抽取出来单独作为插件，
但我忙着实现自动化 JOIN、自动化子查询、存储过程 等 各种一直没时间去做这个，他就自己搞了一个出来： 库非常轻量，只有 JSON -> SQL，可以更灵活的定制，但数据库功能完善度接近 APIJSONORM 了，文档也非常详细， 第三方 APIJSON 解析器，将 JSON 动态解析成 SQL。可以点 Star 支持下作者哦 ^_^ https://github.com/Zerounary/APIJSONParser |
|
180
TommyLemon OP @murmur 所有的关键词都是相关的哦，APIJSONORM 依赖了 fastjson 做 JSON 封装与解析，
APIJSON-iOS 用的是 Swift 语言开发的，APIJSON Node 版 apijson 使用 TypeScript 编写 |
|
181
TommyLemon OP @my8100 0，不需要写任何测试代码， 自动化接口管理平台
http://apijson.org/ 提供 前后对比自动化接口测试 和 机器学习自动化接口测试， 都是 不需要写任何代码，不需要配置任何校验规则 的，看视频试试就知道了 |
|
182
TommyLemon OP @my8100 不过我上面说的 0 覆盖率是指业务接口；
https://i.youku.com/apijson 如果是业务层的 远程函数，那就是 100%（自动查询所有远程函数并逐个调用）； 如果是 APIJSONORM 库的 远程函数 功能，那也有 80%（覆盖无参数，多参数，除了 boolean 的其它 JSON 类型） https://github.com/APIJSON/APIJSON/blob/master/APIJSON-Java-Server/APIJSONBoot/src/main/java/apijson/demo/server/DemoFunction.java |
|
183
my8100 2019-06-01 10:46:30 +08:00 via iPhone
代码覆盖率是 0 ？还是说这个指标目前是未知数？
|
|
184
TommyLemon OP @my8100 代码覆盖率 0 是指业务接口，直接使用 自动化接口测试即可，
里面已经放了 143 个测试用例（默认业务需求测试账号 60 个，APIJSON CRUD 各种功能测试账号 83 个） |
|
185
TommyLemon OP @thisisgpy “最主要的是，码云那个证书并没有一毛钱作用。码云上的用户啥水平大家心里没点数么？”
厉害厉害，把您自己拿到的更有价值的东西、你更好的成就 show 给大家看看，让大家都瞻仰下您这位大神 |
|
186
my8100 2019-06-01 11:02:43 +08:00 via iPhone
“总结这个报告：
总共 10617 行代码，16 个「可能」的 bug，24 个改进建议， (1 - bugs/lines) 高达 99.85% 。 可见 APIJSON 代码非常严谨可靠。” 因为我也是第一次见到这种计算方法，想请教楼主是如何看待这个商业工具的计算结果和传统意义的代码覆盖率之间的关系？这个工具不能顺带输出代码覆盖率吗？ |
|
187
TommyLemon OP |
|
188
TommyLemon OP @blindpirate @carlclone 两位说我是培训班 /培训机构出来的，我不知道该如何证明不是，
但从法律上来讲，谁主张谁举证，麻烦提供证据，谢谢！ By the way，对于培训班 /机构，我就不发表自己的看法了，以免引战。 |
|
189
TommyLemon OP @my8100 具体你可以下载报告，issue 里提供了链接，还可以去官网看看，issue 里也有官网链接
|
|
190
my8100 2019-06-01 12:09:06 +08:00
简单看了下报告： “本次分析时间 2018 年 11 月 16 日”， “ 10617 代码行数”， “ 40 总缺陷”， “高危 - 2 严重 - 3 一般 - 11 建议改进 - 24 ”。
似乎没看到“(1 - bugs/lines) 高达 99.85%”。 |
|
191
TommyLemon OP @my8100 最后这个我的总结的 (1 - 16/10617) = 99.85%
而且这 16 个是 [可能] 的 bug，已经确认有几个是误判，并非真的 bug，所以实际上 99.85% 已经“谦虚”过了 |
|
192
TommyLemon OP @TommyLemon 确实是误判为 bug 的报告用例
src/main/java/zuo/biao/apijson/server/AbstractSQLConfig.java: 897 （可信度: 65%） zuo.biao.apijson.server.AbstractSQLConfig.putWhere(String, Object, boolean)中 AbstractSQLConfig.combine 可能的空指针解引用 对应实际文件 https://github.com/APIJSON/APIJSON/blob/d8cfc9e6be87bd6116ecf8a125a52021f0154761/APIJSON-Java-Server/APIJSONLibrary/src/main/java/zuo/biao/apijson/server/AbstractSQLConfig.java 内方法 AbstractSQLConfig.putWhere 实际上在前面已经用 combine = getCombine(); 做了处理，return 的值不会是 null ```java @NotNull @Override public Map<String, List<String>> getCombine() { List<String> andList = combine == null ? null : combine.get("&"); if (andList == null) { andList = where == null ? new ArrayList<String>() : new ArrayList<String>(where.keySet()); if (combine == null) { combine = new HashMap<>(); } combine.put("&", andList); } return combine; } ``` |
|
193
my8100 2019-06-01 12:24:30 +08:00
“最后这个我的总结的 (1 - 16/10617) = 99.85%”
好的，明白了。 |
|
194
TommyLemon OP @TommyLemon 确实是误判为 bug 的报告用例 2
src/main/java/zuo/biao/apijson/JSONObject.java: 411 （可信度: 95%） 1 这里比较了 clazz 和 null，说明 clazz 可能为空指针 2 调用 clazz 的 java.lang.Class.getName 方法(使用可疑的空指针) 对应实际文件 https://github.com/APIJSON/APIJSON/blob/d8cfc9e6be87bd6116ecf8a125a52021f0154761/APIJSON-Java-Server/APIJSONLibrary/src/main/java/zuo/biao/apijson/JSONObject.java 内方法 ```java @Override public Object put(String key, Object value) { if (value == null) { Log.e(TAG, "put value == null >> return null;"); return null; } if (StringUtil.isEmpty(key, true)) { Class<?> clazz = value.getClass(); if (clazz == null || clazz.getAnnotation(MethodAccess.class) == null) { throw new IllegalArgumentException("puts StringUtil.isNotEmpty(key, true) == false" + " && clazz == null || clazz.getAnnotation(MethodAccess.class) == null" + " \n key 为空时仅支持 类型被 @MethodAccess 注解 的 value !!!" + " \n 如果一定要这么用，请对 " + clazz.getName() + " 注解！" + " \n 如果是类似 key[]:{} 结构的请求，建议用 putsAll(...) ！"); } key = value.getClass().getSimpleName(); } return super.put(key, value); } ``` 406 行 Class<?> clazz = value.getClass(); Class 是对象声明后就有的，到执行这行前 value 已经判断过，又不会为 null， 所以实际上 clazz 不会为 null，407 行 if (clazz == null || clazz.getAnnotation(MethodAccess.class) == null) { 中 clazz == null 是一个冗余的判断，后面删掉了，实际上 411 行 clazz.getName() 永远不会因为 clazz == null 而导致 throw NullPointerException， 所以这也是一个误判为 bug 的用例。 其它的你自己找吧，太费时间了，我也没有全部都验证过，即便假设只有这两个是误判，那就是 (1 - bugs/lines) = (1 - 14/10617) = 高达 99.868136% |
 |
195
sagaxu 2019-06-01 14:59:28 +08:00 via Android
大家放过楼主吧，以前是好战了些，现在的文案已经很 OK 了
|
 |
196
primordial 2019-06-01 16:03:19 +08:00
支持楼主，我先在个人项目上试用。
|
|
197
TommyLemon OP @primordial 感谢支持 ^_^
|
|
198
TommyLemon OP @sagaxu 哈哈
|
|
199
TommyLemon OP @yinzhili 采用敏捷开发方式，目前就 49 个类，没必要分太多包导致不好找，
杀鸡焉用牛刀，按照场景选择合适的方式就好。 Log 为了不依赖其它库就加了个简单的类，自己的工程里随你用什么方式， 后续也会提供扩展，用户可重写相关方法，自由使用 Log4J 等打印 APIJSONORM 的日志。 |
|
200
TommyLemon OP @polebug 放荣誉（首选得有）、使用的企业 /项目 的开源项目多了去了，连阿里的也是，
这也是为了让用户放心，免得总有人问“这个项目有没有 /有哪些公司在用呢？”之类的。 |
Select Language