这是一个创建于 2235 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近写后端语句写到头疼，绕来绕去就是为了执行个 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 友实践过呢？
 |
1
noNOno 2018-10-10 10:49:48 +08:00
虽然 lz 说了不考虑性能问题
但是业务逻辑在存储过程里,意味着每次都会在数据库层面处理业务逻辑. 十个点击,就是十个多表查询,库直接炸了. 真的没必要啊 |
 |
2
lichao 2018-10-10 10:52:24 +08:00
根本原因是用的 ORM 不好用么？
|
 |
3
jitongxi 2018-10-10 10:53:06 +08:00
往前倒退 10 年
|
 |
4
marrysail 2018-10-10 10:57:23 +08:00
觉得不可取。06 年这么干过。
|
 |
5
likuku 2018-10-10 11:01:27 +08:00  1
很久以前一些老企业自家 ERP 之类就这么玩，结果就给半永久绑死在某些大厂的 DB 上了
|
 |
6
l00t 2018-10-10 11:03:34 +08:00 1
单从开发效率上考虑完全没问题啊。可行。
这种方案的不利之处是不方便扩展，以及不方便换数据库。如果没有这两方面的需求的话，那就随意好了。 |
 |
7
iloveyouso OP 1
@noNOno @marrysail 服务器我感觉还算是很高配的，128G 内存，而且处理器也不差。主要是并发量不高，一天能有一次查询就算好了，查询条件大部分都是 where，很少 join，最多就是 join 一个常量配置表，需求也比较稳定，就是想快速完成这些项目，否则现在弄起来好费时间
@jitongxi 这种实现方式的确很古老。。但是开发效率至少，搞好之后再改动的可能很小，相当于是一次性项目开发吧，我不太想一步步优雅的弄这些重复的生成 ORM，Mapper，Controller，只想开发效率至上 @lichao Java 的 ORM 还有 MyBatis 都很好，就是感觉不如直接撸 SQL 语句来得快，总感觉大部分时间都在处理 Controller 和 Mapper 之间的关系了，想早点下班，唉 |
 |
8
smilenceX 2018-10-10 11:13:56 +08:00 3
你只是还没到 Debug 的时候。
|
|
9
likuku 2018-10-10 11:14:56 +08:00 2
@iloveyouso 既然是“一锤子买卖”，做好就很少动了，那么简单粗暴直接上就对了。赞成票+1
|
 |
10
hector 2018-10-10 11:22:54 +08:00
只写存储过程，然后根据存储过程的参数写个工具自动生成后端查询代码，有几个项目上线后还换数据库的，想多了
|
 |
11
murmur 2018-10-10 11:24:41 +08:00 1
印象中有一些奇葩的架构师喜欢这种设计
理由是业务逻辑都是存储过程写的 支持热部署不需要重启。。。 |
 |
12
Cbdy 2018-10-10 11:30:03 +08:00 1
Java 的话，JDBC Template 这种抽象很合理了，等 Java12 出了，支持多行字符串就可以告别 MyBatis 了（当然，我现在也不用）
ORM 的话，用 JPA 吧。你这套东西，恕我直言，半吊子的设计 |
 |
13
TommyLemon 2018-10-10 12:03:24 +08:00
存储过程的编码和调试都很麻烦，而且迁移数据库时一堆业务代码也得跟着迁移。
不就是写 SQL，Mapper，POJO，可能还有 Swagger 注解 写烦了么？ 用 APIJSON 的自动化 API 就好了， 自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果， 期间自动校验权限、结构、内容，自动防 SQL 注入。 通过自动化 API，前端可以定制任何数据、任何结构！ 大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！ 前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！ 后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！ 在线解析 自动生成文档，清晰可读永远最新 自动生成请求代码，支持 Android 和 iOS 自动生成 JavaBean 文件，一键下载 自动管理与测试接口用例，一键共享 自动校验与格式化 JSON，支持高亮和收展 对于前端 不用再向后端催接口、求文档 数据和结构完全定制，要啥有啥 看请求知结果，所求即所得 可一次获取任何数据、任何结构 能去除重复数据，节省流量提高速度 对于后端 提供通用接口，大部分 API 不用再写 自动生成文档，不用再编写和维护 自动校验权限、自动管理版本、自动防 SQL 注入 开放 API 无需划分版本，始终保持兼容 支持增删改查、模糊搜索、正则匹配、远程函数等 后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！ 创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^ https://github.com/TommyLemon/APIJSON |
|
14
TommyLemon 2018-10-10 12:06:25 +08:00
@TommyLemon APIJSON 还支持不需要部署的“热部署”哦。
前端改变 查询 的 JSON 参数， 就会生成不同的 SQL， 后端代码不需要做任何改动； 后端改变数据库中 增删改 的校验规则， 就会加载新的规则来校验， 后端代码还是不需要做任何改动。 这样就实现了“没有部署过程” 的“热部署”。 后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！ 创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^ github.com/TommyLemon/APIJSON |
 |
15
crayontxx 2018-10-10 12:19:21 +08:00
我现在的公司就是把部分的 CRUD 放在了 sproc 里
理由大概就是下面这几点 - 方便多种 server 共享 这部分的逻辑，顺便屏蔽实现 - 修改业务只要改 sql 就好，不用再去碰 server 的代码 - 简单 |
 |
16
AlkTTT 2018-10-10 14:07:50 +08:00
我觉得单是 crud 项目，用 springboot+mybatis 就挺好的
没业务逻辑可以不要 service，sql 语句不想写到 xml 里，可以直接用注释写在 mapper 里 |
 |
17
rockyou12 2018-10-10 15:20:26 +08:00
lz 是没用过 spring data jpa 这种 orm 吧，哪用写什么 sql ……
|
|
18
TommyLemon 2018-10-10 15:41:02 +08:00
@rockyou12 @Cbdy
楼主看了这个例子，会觉得 JPA 一样很烦的 https://blog.csdn.net/quwenzhe/article/details/54705835 看上面的 TommyLemon 的回复，用 APIJSON 自动化 API 都不用写代码就能请求接口了 |
 |
19
ranoff 2018-10-10 16:11:37 +08:00
在业务层写方法当存储过程用可好?
|
|
20
rockyou12 2018-10-10 16:58:47 +08:00
@TommyLemon 一般除非是统计其实不会 join 4,5,6,7 个表这么多的，一般的业务即使不用 @OneToMany 这种注解来配关系，也可以很简单的完成业务，无非就是代码量多一点。
其实 spring 自己也有像 Rest Repository 这种只定义 repo 不用写 controller 的框架。但不管哪种代码生成类的框架，都不可能完全契合业务，少些几个接口，搞不好以后修改业务会无比困难。具体怎样合适也只能 lz 自己看业务了。 但用存储过程过业务除非是搞外包一锤子买卖，绝对是自己给自己埋地雷。 |
|
21
TommyLemon 2018-10-10 17:18:44 +08:00
@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 |
|
22
Cbdy 2018-10-10 17:27:50 +08:00
@TommyLemon
JDBC Template 原生 SQL 解决复杂查询 JPA 解决简单增删改查 MyBatis 方便动态 SQL 和多行字符串 Spring Data REST 直接根据数据表生成 REST API 成熟而流行的方案很多了，不要去做“半吊子的设计” 为什么不用数据库的储存过程？因为复杂度，这么做不能 handle 软件开发的复杂度（调试复杂、维护复杂、依赖平台、不好懂），所以不流行 |
 |
23
cuiweiqiang 2018-10-10 17:56:37 +08:00 1
@Livid #13 #14 #21
|
 |
24
msg7086 2018-10-11 06:59:09 +08:00
|
|
25
TommyLemon 2018-10-11 11:27:28 +08:00 1
在不相关的帖子下回答才是硬广吧，对读者有帮助的回答就是有意义的。
V2EX 作为一个技术社区，开诚布公、有理有据地讨论技术问题， 不灌水，不言语攻击，不做任何违反法律和道德的事情， 又有什么不妥呢？ |
|
26
TommyLemon 2018-10-11 11:28:08 +08:00
|
|
27
TommyLemon 2018-10-11 11:32:38 +08:00
|
Select Language