所有查询与配置信息都通过 SQL 语句+存储过程，这样的架构是否可行？

[iloveyouso]

最近写后端语句写到头疼，绕来绕去就是为了执行个 SQL 语句，为了 Join 一个表又要写 Controller 又要写 Mapper 烦死了，也没有什么高并发、锁之类的这种层面的问题需要考量，纯粹的 CRUD 项目，甚至绝大部分都是 SELECT，之前效率太低了！
所以准备下一个项目重新设计一下架构，想把很多后端查询的功能都放在存储过程里面，只需要提供条件参数，我就能给你查出来。目前还不考虑性能问题，毕竟简单的 CRUD 项目就是讲究地简单粗暴，多快好省！
大家看看我这样的策略可行不？最优考虑的就是开发效率，这是我简单下一个项目的架构：
1, 每个查询功能作为一个 xml 文件，被统一放在 WEB-INF/crud 文件夹下 2, xml 文件包含存储过程执行内容以及对应的 action 名称(没有就文件名作为 action 名)，目前先简单点，就直接<root><query></query></root>
3, Java 配合 Spring，启动服务后解析 WEB-INF/crud 的 xml 文件，并且动态注册 controller，添加分页，排序等其他功能

查询过，好像大部分存储过程都是金融银行这类开发喜爱的，有没有 V 友实践过呢？

[TommyLemon]

@rockyou12
生成静态代码肯定是不可能完全切合业务需求的，还得改造，后续也得继续维护。
维护一段时间后，代码已经发生了很大的变化，整合生成的代码还不如直接改方便。

所以 APIJSON 就不是生成静态代码这个思路，而是
自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。

前端改变 查询 的 JSON 参数，
就会生成不同的 SQL，
后端代码不需要做任何改动；

后端改变数据库中 增删改 的校验规则，
就会加载新的规则来校验，
后端代码还是不需要做任何改动。

自动化的 JOIN 用起来也非常方便，不需要后端写代码，直接前端传的 JSON 参数加一行
"join": "</User/id@" // LEFT JOIN User ON User.id = XXX.userId

这样就能很好地切合业务需求了。

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

[Cbdy]

@TommyLemon
JDBC Template 原生 SQL 解决复杂查询
JPA 解决简单增删改查
MyBatis 方便动态 SQL 和多行字符串
Spring Data REST 直接根据数据表生成 REST API

成熟而流行的方案很多了，不要去做“半吊子的设计”

为什么不用数据库的储存过程？因为复杂度，这么做不能 handle 软件开发的复杂度（调试复杂、维护复杂、依赖平台、不好懂），所以不流行

[cuiweiqiang]

@Livid #13 #14 #21

[msg7086]

@TommyLemon 看了你的回复历史，硬广多得有点过分啊。
虽然是开源软件，但是也请不要如此 spam 论坛。
不要逼得管理员把你项目加进关键词黑名单以后一提到就直接 ban IP 的地步。

[TommyLemon]

在不相关的帖子下回答才是硬广吧，对读者有帮助的回答就是有意义的。
V2EX 作为一个技术社区，开诚布公、有理有据地讨论技术问题，
不灌水，不言语攻击，不做任何违反法律和道德的事情，
又有什么不妥呢？

[TommyLemon]

@Livid @msg7086

[TommyLemon]

@Cbdy
请用依据来说明为什么是“半吊子的设计”，我洗耳恭听，谢谢。
这些实实在在的优势，无论是从 在线体验工具、文档与源码、客户端 App Demo 上都能看出来。