2023-09-18 10:53
市面上已经有了JdbcTemplate\JPA\Mybatis\Mybatis plus\Querydsl\JOOQ\BeetlSQL等半orm或全orm。但代码里写复杂的sql联表语句、复杂的聚合语句,无意义,属于orm功能的过度设计。因为大部分场景下,多联表的、复杂的语句都是需要在sql客户端里进行执行验证的,是先有sql再有代码。如果使用代码生成,那么这个验证就变成了要写一堆的代码来验证。倒不如jpa的思路,简单的单表的查询直接通过方法命名查询,自动映射成单表的查询语句,代码阅读也一目了然。复杂的sql,直接用原生语句书写,jdk14+有了text blocks,代码里写sql、将代码里的sql复制出来再也不是事儿了。orm想一劳永逸杜绝写sql既不可能也无必要,orm应该只做orm擅长的(数据库表与对象的映射,除此之外的功能少做,少即是多),因为即使再强大的orm,也只能写出99%等价于sql的代码,却总有1%复杂的sql语句无法用orm翻译,或者需要很大的sql翻译成对应java的多项成本,带来的心智负担让orm推广也天然存在阻力。对于大部分普通应用,本人推崇80%jpa + 20%jdbcTemplate,基本能够应对所有的场景。jpa来实现数据的增删改查OLTP场景,主打一个不用写sql,20%的OLAP型场景复杂sql,用原生sql + JdbcTemplate/JdbcClient映射结果集即可。
2023-09-17 16:51
看着怎么像是在学C#
2023-09-17 12:50
似乎可以写一个简单兼容支持Jpa?
2023-09-16 19:27
我觉得可以参考C#,写代码里
2023-09-16 21:05
这个最初还真是从 c# 那儿移过来的:)
2023-09-16 18:31
别在orm里卷了
2023-09-16 21:05
需要的些不同的东西:)
2023-09-16 16:42
我觉得可以学下BeetlSQL的Markdown用法
2023-09-16 21:06
已经有 a 了,难道搞个 a' :)。。。市场需要的是 b
2023-09-21 17:29
不是提供了xml写SQL吗?既然提供自定义SQL为什么不选择一个更好的方式,目前用来看beetlsql Markdown用法是最好的,没有更好的,为什么不用目前最好的?如果东西只是为了多不是为了更好,哪后来者的意义何在?
2023-09-21 18:15
北方想不通:都有饺子了,为什么南方人还要吃汤圆。。。要能看到更大的世界。
2023-09-21 18:30
而且北方人怎么想,都觉得饺子就是最好的。
回复 @
{{emojiItem.symbol}}
返回顶部
顶部