这是一个创建于 1490 天前的主题，其中的信息可能已经有所发展或是发生改变。
不是 JPA，不是 Mybatis，Java 类里直接 String sql ="select xxxx" ，然后调用一个封装的 xxx.select()方法，大家如何看待这种行为？
第 1 条附言 · 2020-10-23 17:31:23 +08:00
不是 Demo 哦，挺大的项目，CRUD 都是这样写的。。。。个人找不到啥优点，参数代码拼接，极难维护，想看看大家怎么看-_-||
 |
1
chendy 2020-10-23 16:11:29 +08:00
见过的这种写法都很水，一般连接池也没有，事务，异常处理也不完善
但是项目不重要的话也就无所谓了… |
 |
2
libook 2020-10-23 16:11:57 +08:00
有很多看起来“非主流”的代码可能是菜鸡写的烂代码也可能是大牛精心构造，得看这么写的理由是什么，有没有更好的方案。理由说得过去就合理，说不过去就不合理，只要满足高可读性、高可靠性、高性能的原则就是好代码。
|
 |
3
zoharSoul 2020-10-23 16:13:25 +08:00
你说的是 jdbc?
我觉得没啥问题啊.. 有点就是简单查询下没必要引入个 jpa 吧 |
 |
4
lxk11153 2020-10-23 16:14:26 +08:00
JdbcTemplate ?
|
 |
5
cpstar 2020-10-23 16:23:17 +08:00
最终不还要翻译到 SELECT ？
这种还好，就是不知道条件那里怎么写，如果写成 String sql = "SELECT * FROM xxx WHERE id='"+id+"'"，那就真蜜汁自信了。 |
 |
6
LowBi 2020-10-23 16:24:06 +08:00 via Android
哈哈哈，目前公司写接口就这样，啥也不是
|
 |
7
iisky1121 2020-10-23 17:20:58 +08:00
？？？，jdbc 不是这样的吗？
|
 |
8
oma1989 2020-10-23 17:26:52 +08:00
刚写了个调用 API 接口取数，JDBC 直连落库的一次性 JAR .....
|
|
9
oma1989 2020-10-23 17:27:55 +08:00
简单的功能简单写，总不至于大炮打苍蝇吧.....
|
 |
10
Bromine0x23 2020-10-23 17:32:36 +08:00
要是 Java 多行字符串给力点的话，早就直接用 JdbcTemplate 了
|
 |
11
vincent7245 2020-10-23 17:34:40 +08:00
这个需要具分析了，看业务需求，比如并不是所有的 jdbc 都要用连接池，甚至有的项目绝对不能用连接池。还有就是可能受限于项目规模没必要用第三方的框架，没必要大炮打蚊子。不过直接 String sql = “”; 确实是有点 low，好歹封装一下吧
|
 |
12
xiangyuecn 2020-10-23 17:34:58 +08:00
返璞归真的写法。前提该懂的都懂。是最高效最简洁的写法。对于维护难易，就算是 Mybatis 也都是各有千秋，评价不了。
但看这个 sql 用 String 类型，应该是菜鸟，100%进行了字符串无任何处理的拼接。 |
 |
13
nulIptr 2020-10-23 17:40:49 +08:00
曾经我也用 ef，后来发现还是 dapper 好用。
模板生成增删查改方法，更复杂的方法直接上 sql 写好注释，复杂业务下 sql 可维护性比 orm 高 再说你们用 orm 的就没见过慢查询吗。。。 |
 |
14
FireFoxAhri 2020-10-23 17:42:40 +08:00
之前用 scala 写 play 框架，就是 anorm 。。封装了下 jdbc，全部手写 sql
|
 |
15
koal 2020-10-23 17:48:16 +08:00
手工写 mysql 到 java 代码中厮混，就是耍流氓！
|
 |
16
Qlccks2 2020-10-23 17:56:10 +08:00
得看需要才知道合理不合理，如果整个系统全是这么写的肯定不合理。
|
 |
17
lichao 2020-10-23 17:57:43 +08:00
古代的项目都是这么写的
|
 |
18
kanemochi 2020-10-23 18:01:09 +08:00
项目很简单，就几个 sql 的规模的话也未尝不可
|
 |
19
zgzhang 2020-10-23 18:07:04 +08:00
注入教做人
|
 |
20
SabaPing 2020-10-23 18:12:45 +08:00
我们就这么写啊，直观，sql 不留坑，所见即所得。
当然楼上老哥说的好，具体分析，看业务需求 |
 |
21
yuhuan66666 2020-10-23 18:13:33 +08:00  1
碰见过通过 http 传 sql 到另一个系统执行的
|
 |
22
yinzhili 2020-10-23 18:17:06 +08:00
都是赶时间引起的
|
 |
23
wanguorui123 2020-10-23 18:18:16 +08:00 via iPhone
碰见过一个 sql 比我写的作文还长的栗子
|
 |
24
fhsan 2020-10-23 18:20:36 +08:00
具体问题具体分析，不要生搬硬套，懂得都懂
|
 |
25
wysnylc 2020-10-23 18:28:48 +08:00
哦吼,注入
|
 |
26
superrichman 2020-10-23 18:31:53 +08:00 via iPhone
sqlmap 狂喜（不是
赶紧跑吧，说不定哪天就被脱裤（划掉 |
|
27
wysnylc 2020-10-23 18:39:31 +08:00
@superrichman #26 我真佩服他们不怕死的劲头
|
 |
28
qwerthhusn 2020-10-23 18:43:09 +08:00
主要是 Java 不支持多行文本（除了最新版本，但是这个应该没真正的项目去用），所以写出来的多行 SQL 没法看
但是如果换了 Kotlin，有多行文本的话，就好多了 |
 |
29
wowo243 2020-10-23 19:03:01 +08:00
我们现在的项目里就是这么写的。。。。
用的是 spring jdbc |
|
30
wowo243 2020-10-23 19:05:55 +08:00
感觉好处就是直接写 sql，能针对性的优化吧，囧；
还有就是啥都能自己造； 坏处，就是好像这玩意没那么流行，感觉更常见的还是 mybatis |
 |
31
wangritian 2020-10-23 19:20:52 +08:00
我查询全写 sql，增删改用对象
|
 |
32
wangyanrui 2020-10-23 20:09:09 +08:00 via Android
ORM + 充血模型 万岁
|
 |
33
Cbdy 2020-10-23 20:14:09 +08:00 via Android
|
 |
34
codingbody 2020-10-23 21:42:05 +08:00 via iPhone
我以前公司项目全是 jdbcTemplate，现在做 ETL 连 Spring 都没有映入。
|
 |
35
iTanX 2020-10-23 22:11:28 +08:00
@chendy
有没有连接池取决于获取到的是什么数据源，有没有事务取决于数据源有没有事务控制器控制，异常处理完善不完善取决于楼主说的那个 select()方法是否写的漂亮。你确定很水？事实上，很多场景 JDBC 才能满足需求，mybtis 等框架不适用于所有业务场景的 |
 |
36
hafuhafu 2020-10-23 22:13:17 +08:00
新项目，除非只写个位数的简单 sql，不然就算是全手写也肯定是 mybatis 更方便和易读吧，加个依赖可能一两分钟的事吧。
老项目可能是遗留呢，以前的人都这么写，接盘的人也纷纷跟着写。 |
 |
37
jzmws 2020-10-23 22:18:23 +08:00
我就是这样写的 , jpa 预编译的 动态生成 sql 语句
|
 |
38
fansangg 2020-10-23 23:38:39 +08:00
怎么办，Google 的 room 也是在类里写 sql 语句
|
 |
40
wflwq 2020-10-24 04:36:23 +08:00
有个需求要批量执行某一条更新语句 N 次，碍于 mybaits 性能，采用了原生的 batch 模式，语句就直接怼代码里了。
仔细想想写 xml 文件里解析出来也便于维护一点 |
 |
41
melkor 2020-10-24 07:22:42 +08:00 via iPhone
@yuhuan66666 这脑洞，长见识了
|
 |
42
jzphx 2020-10-24 09:12:29 +08:00
我见过，之前接手了老外同事的项目，原汁原味的 sql，数据库连接池都不用。看到有个热帖有人回复说国内码农不写注释嘛，国外的摸鱼码农也不写注释。
|
 |
43
Achiii 2020-10-24 09:53:53 +08:00
这样不怕注入吗
|
 |
44
forbreak 2020-10-24 10:45:21 +08:00
如果参数不是通过+号拼接，那就是正常行为。
|
 |
45
PDX 2020-10-24 10:56:11 +08:00 via iPhone
这样写没毛病吧？
|
 |
46
rodrick 2020-10-24 11:23:47 +08:00
我这甚至有前端动态拼 sql 在请求接口里，后台直接拿封装好的一套方法拿出这个接口的 sql 去跑的。。
|
 |
47
sun1991 2020-10-24 11:23:53 +08:00
@nulIptr 同 EF 转 Dapper 爱好者.
感觉简单的事情 ORM 能做的挺好, 但是复杂度上去了, ORM 同样处理不好, 还不如直写 SQL 来的简单明了. |
 |
48
yjxjn 2020-10-24 11:36:40 +08:00
@xiangyuecn 说的对，最简洁高校，除了不易维护，其他都还好。。
|
 |
49
xumng123 2020-10-24 12:21:57 +08:00 via iPhone
框架大多数都提供原生 sql 访问，这样写也不是不行，比如数据访问层无法满足需求
|
 |
50
shadownet 2020-10-24 14:44:07 +08:00
就是你们这些观点让原本简单的事情复杂化,本来一个 sql,10 毫秒搞定的,外面套一堆东西,最后 100 毫秒都不够,然后让客户加硬件
|
 |
51
janus77 2020-10-24 14:57:00 +08:00
我们的项目需要跑每日报表，计算量大 计算逻辑复杂，就是直接 jdbc，不然性能跟不上
|
 |
52
elintwenty 2020-10-24 15:50:22 +08:00
看项目复杂度，十万行和五百行当然不会是同一个结构。但是直接传 sql 需要处理注入等安全问题吧？
|
 |
53
DoctorCat 2020-10-24 23:49:29 +08:00
小明：劳资刚从写 js 转 java，明明 run 起来了但你竟然告诉我这么写不行？
|
 |
54
skinny 2020-10-25 09:31:02 +08:00
只要不是直接拼接字符串，用户输入用绑定参数，不用视之为洪水猛兽。
|
 |
55
php01 2020-10-25 16:19:47 +08:00
我是万万没想到居然有这么多人支持直接写 sql，看来我在 java 里也能混口饭吃了
|
|
56
Bromine0x23 2020-10-25 18:30:19 +08:00
首先要明确：直接写 SQL≠拼接参数。
拼接参数是有安全问题，但是只要是用绑定参数，直接写 SQL 就不存在安全隐患。 |
 |
57
CantSee 2020-10-28 14:57:26 +08:00
亚信?
|
Select Language