@TommyLemon #68 楼 和 #32 楼

@blless
对的，缓存能解决大部分性能问题，复杂的 SQL 也很难维护，
只有真的是那种非常复杂的查询，各种 JOIN、子查询、case 一起用，代码在 1 屏以上的才需要手写 SQL。
可以看下我上面的回答，APIJSON 是一个自动化的 ORM 库，不用后端写代码，Star 已超 Hibernate, JPA 等。

@TommyLemon APIJSON 是提供了 自动化的权限控制、数据和结构校验、自动防 SQL 注入 的。

@ghos 可以这么理解。
有人问过 “前端为什么不直接发送 sql 到后端更简单直接”

我的回答是：
解析 SQL 语法，再校验权限、结构、内容，最后再转回 SQL，
不说性能问题，真要这么好搞业内也应该有不错的开源方案了。

而且 SQL 不能直观地反映返回 JSON 的数据结构，
APIJSON 就能做到看请求知结果，所求即所得。

APIJSON 的 提取字段、远程函数 功能也不是 SQL 方案能方便地实现的。
还有 自动加注释、自动生成封装请求 JSON 的代码，用 SQL 方案实现也很困难，甚至根本不可能准确地实现。

为什么要用 APIJSON ？或者 APIJSON 有什么用？
https://github.com/TommyLemon/APIJSON/wiki

@no1xsyzy
“把所有东西一股脑给你，然后让你自己丢弃，凭空浪费数据库计算资源和带宽资源。”
这就是 ORM 库没有封装好的结果，用 APIJSON 就能很简单直接地指定每张表的字段，
自动解析生成的 SQL 里 SELECT 的就不是 * , 而是 "@column": "id,name" 对应的 `id`,`name` 了。

@no1xsyzy
@nutting
@visonme
Hibernate 这种对于稍微复杂一点的关联查询写法都比较麻烦，代码不够直观，一般非单表的 CRUD 确实不如手写 SQL。
APIJSON Star 已经超过它了，并且对于简单的 CRUD、比较复杂但不是非常复杂的查询 就支持得很好，非常直观：
{
"[]": {
"count": 5,
"join": "&/User/id@,</Comment/momentId@",
"Moment": {},
"User": {
"id@": "/Moment/userId",
"@column": "id,name"
},
"Comment": {
"momentId@": "/Moment/id"
}
}
}

会自动解析为
SELECT `Moment`.*,`User`.`id`,`User`.`name`,`Comment`.* FROM `Moment`
INNER JOIN `User` ON `User`.`id` = `Moment`.`userId`
LEFT JOIN `Comment` ON `Comment`.`momentId` = `Moment`.`id`
LIMIT 5 OFFSET 0

APIJSON 目前已实现：
大体功能：增删改查、分页查询、统计与验证、注册登录、模糊搜索、结构校验、角色及操作权限校验、数据保护、远程函数调用等
操作方式：增、删、改、查、调用远程函数
操作对象：单个对象、可关联的多个对象、数组等
请求方法：GET,HEAD,GETS,HEADS,POST,PUT,DELETE
请求结构：{Table:{...}}、{Table0:{...},Table1{...},Table2:{...}...}、{"[]":{Table:{...}}}、{"[]":{Table0:{...},Table1{...},"Array0[]":{...},...}}等各种组合和嵌套
返回结构：对应请求结构的各种 JSON 结构。
功能符号：

"key[]":{} // 查询数组

"key{}":[] // 匹配选项范围

"key{}":"<=10;length(key)>1..." // 匹配条件范围

"key()":"function(arg0,arg1...)" // 远程调用函数

"key@":"key0/key1.../targetKey" // 引用赋值

"key$":"%abc%" // 模糊搜索

"key~":"^[0-9]+$" // 正则匹配

"key%":"2018-01-01,2018-10-01" // 连续范围

"key+":[1] // 增加 /扩展

"key-":888.88 // 减少 /去除

"name:alias" // 新建别名

"@column":"id,sex,name" // 返回字段

"@group":"userId" // 分组方式

"@having":"max(id)>=100" // 聚合函数

"@order":"date-,name+" // 排序方式

"@schema":"sys" // 集合空间

"@database":"PostgreSQL" // 跨数据库

"@role":"LOGIN" // 访问角色
详细说明见通用文档中的 [功能符]( https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2)
创作不易，GitHub 右上角点 Star 支持下吧 ^_^

@szq8014 对的，针对不同的场景选择合适的工具就好。可以看下我上面的回答

@binge 说的很对，SQL 肯定是要掌握的，不仅在于方便优化性能，还在于方便使用 Navicat 等数据库工具来调试。

@liuxey @passerbytiny @micean @visonme @xschaoya
一般 ORM 对不是很复杂的查询都能做到一定程度的优化的，能提高性能下限，但也会拉低上限。
所以不是很复杂的 SQL 用 ORM 做很合适，太复杂的还是手写 SQL 针对性更好。

APIJSON 的自动化 JOIN，自动解析生成的 SQL 和手写的 除了多了引号外几乎没有区别，
至于连表的数量也没有限制，3 张表不算什么。
{
"[]": {
"count": 5,
"join": "&/User/id@,</Comment/momentId@",
"Moment": {},
"User": {
"id@": "/Moment/userId",
"@column": "id,name"
},
"Comment": {
"momentId@": "/Moment/id"
}
}
}

会自动解析为
SELECT `Moment`.*,`User`.`id`,`User`.`name`,`Comment`.* FROM `Moment`
INNER JOIN `User` ON `User`.`id` = `Moment`.`userId`
LEFT JOIN `Comment` ON `Comment`.`momentId` = `Moment`.`id`
LIMIT 5 OFFSET 0


创作不易，GitHub 右上角点 Star 支持下吧 ^_^
github.com/TommyLemon/APIJSON

@TommyLemon CRUD 和 比较复杂但不是很复杂的查询

@xy90321
一般的互联网应用还是大量存在简单的 CRUD 和 不是比较复杂但不是很复杂的查询 需求的，用 APIJSON 很合适。
对于一堆需要写 1 屏以上 SQL 才能实现需求的 ERP 项目，还是老老实实写原生 SQL 或 Mybatis 这种接近原生 SQL 的代码吧。

@TommyLemon 括号倒是不用手写，但阅读起来麻烦。

UI 测试很难自动化的，虽然谷歌、腾讯、华为等公司提供了工具，
但除了 Monkey 这种随机点按和滑动、基本只能做崩溃测试和压力测试 的工具，
想要精准一点也都得通过手写代码去抓取 UI 组件的值来校验。

至于接口的自动化测试，我只见过一个不用写代码的 接口管理工具，
叫 APIJSONAuto，提供 前后对比测试（免费，开源） 和 机器学习测试（付费，未开源） 。
http://apijson.org

创作不易，GitHub 右上角点 Star 支持下吧 ^_^
https://github.com/TommyLemon/APIJSONAuto

@actar
@ltoddy
@skypyb
@gowk
@fuyufjh
@tabris17
@beginor
Hibernate, Spring Data JPA, QueryDSL 表达力都不够强，
除了单表的增删改查，其它复杂一点的，例如 JOIN 写起来比原生的 SQL 还麻烦，
首先是一堆括号，然后 <, >, !=, <=, >= 等符号还得用 lt, gt, ne, lte, gte 等别扭的写法。
Star 都已经被自动化的 APIJSON 超过了。
https://github.com/TommyLemon/APIJSON

@TommyLemon
前端传一个 JSON：
{
"User": {
"id": 82001
},
"[]": {
"count": 10,
"page": 1,
"Comment": {
"userId@": "User/id",
"@order": "date-"
}
}
}

后端完全自动化解析，不用写代码。
1.自动生成
SELECT * FROM User WHERE id = 82001 LIMIT 1 OFFSET 0

2.自动生成
SELECT * FROM Comment WHERE userId = ${User.id} ORDER BY date DESC LIMIT 10 OFFSET 10

大部分需求都用这个自动化 ORM 库，不需要写代码，逻辑太复杂或对性能要求高的地方就手写 SQL。
它会自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。
github。com/TommyLemon/APIJSON

@TommyLemon 避免不兼容 JVM

对 JVM 平台上 Java，Scala，Kotlin，Groovy，Clojure 都不满意，
希望像 Go 一样保持简单好用，但又避免兼容 JVM，及生态不丰富 等问题。
可以看下 Axis，一起交流探讨
github.com/TommyLemon/Axis-Lang

@TommyLemon 至于形成环形链表的原因我看到问题就猜出来是
多线程并发执行
set.add(key)
时同一个 key 被添加多次，然后导致
valueI = key
valueJ = key
当循环里通过
value = value.next
形成了从 valueI 到 valueJ 的环形链表