这是一个创建于 1867 天前的主题，其中的信息可能已经有所发展或是发生改变。
不是 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 rb6221 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 anteros 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