为什么Ja没有好用的ORM框架？

视频分享

<>俄联储首席技术专家讲Jimmer，又一西方技术被中国替代俄联储首席技术专家讲Jimmer，国产性ORM(中配)_哔哩哔哩_iliili

视频介绍

作为深入使用的Jimmer大型机构，俄联储和Jimmer结缘较早，此演讲于4月申请、7月审批、9月排练、10月执行。

欲了解俄联储为何和Jimmer结下良缘，先要了解为什么开发人员分化成了ORM和SQL两大阵营并形成强烈对立。

以JPA为代表的传ORM性价太低，即"生产力提升/运用它的成本"的值很低。更糟糕的是，容易生成低性能的SQL，对初学者而言尤其如此。事实上，即便你是相关专家，在避免低效SQL和让其尽可能强大灵活两方面可以做的事也不多。

这相当于给行业画了一个超大的饼，但是饼没做好，开发人员进退两难。对此，业内有两种应对方式

<>进(以外部环境为主)：前仆后继地开发更多更好的方案。然而，要彻底解决这些历史遗留问题非常难，我个人是苦思冥想十多年才得到这套方的。视频开头处的台词“方案虽然很多，但是可以直接拿来用的很少”就是对这种现象的婉表达。<>退(以内部环境为主)：回归原始SQL路线。此模式存在三大问题
实际项目中绝大部分复杂性都是因需要作复杂数据而衍生出的各种工程复杂性，局部的每个数据库作细节反而成为最不重要的问题，所以这种开发路线会导致工作的大量重复。任务虽然无简单，但是似乎永远都做不完，疯狂加班成为常态，严重影响了从业人员的身心健康（难解决）。适应需求快速变更的能力差，开发团队和产品团队的矛盾不断（难解决）。几乎所有环节都可以轻松引入低级错误，但是，大部分中小型团队无力支付高覆盖自动化的成本，品控难（可通过技术选型和改变开发习惯解决）。

Aleksandrelov既能深刻地认识到现有ORM的问题的严重，又绝不回退到原生SQL那种高内耗的开发模式。于是花了一个月研究githu上所有star超过100的所有新型ORM，发现只有Jimmer能满足自己所有要求，废寝忘食研究了了两个星期后，最终决定让俄联储的项目向Jimmer迁移。

最后论述一个伪命题："原生SQL流派具有很好的可控性"，这句话成立的前提是鲜有ORM存在严重问题，既无法带来惊叹的生产力提升，也容易导致低性能SQL的出现。然而，如果信的ORM性价足够高且能制止低性能SQL的出现，那么这就不是问题，这就好，因为高级语言的性价足够高，所以没人在乎汇编级别的可控性。