为什么我劝你放弃mybatis

汉北集团

我用过很多年Mybatis——刚开始用的时候还叫Apache Ibatis。有段时间对orm很感兴趣，还把玩了一下Cayenne。后来成为了JPA2.x+Hibernate的使用者，主要因为一本书《Hibernate in action》。对于这两者，我观点如下：
1、别说Hibernate只能做小项目，这是2006年左右就开始流行的说法。Hibernate本身一直在进化，国内外很多大项目用的都是Hibernate。觉得Hibernate对查询不友好的，大概是还没学会Hibernate的黑魔法。
2、当项目业务复杂时，困扰开发人员的绝不是哪个ORM框架，而是领域建模。因为领域建模不但会随着需求变化而变化，还会随着你对需求理解的深入而变化。当量变积累到一定程度，需要发生质变的时候，你会感觉到世界在坍塌，因为好多对象都要面临重建。
3、我觉得，不喜欢Hibernate很正常，每个人都有自己习惯的东西。Mybatis能用在那么多系统中已经证明了它是可行的。何况，在阿里这些企业里，他们有自己的数据库。不但语法与通用数据库有细微差异，而且这些数据库语法还在快速发展变化中。与其频繁更新Hibernate针对这些数据库的驱动，抛弃旧的驱动，还不如让大家徒手写SQL来得省事。
4、国外项目也有使用Mybatis的，例如BPMN引擎activiti/flowable。
5、我也是先建模后生成schema，但不会使用Hibernate直接生成数据库schema。因为你要考虑数据库schema的版本和迁移问题，确保schema的演化过程在迁移时能够被完整reproduce，避免和老库出现差异。这几年流行Liquibase，不妨了解一下。
6、我同意作者一个观点，就是徒手写SQL未必比生成SQL来得高效。徒手写SQL需要通过代码规范对大家的SQL语句进行约束，通过代码评审来确保大家都按规矩执行了。而在我目前带的项目里，原则上是禁止徒手写SQL的，历史经验告诉我这太难管控，到处是坑。只有根据压测结果论证Hibernate无法生成符合效率要求的SQL时才允许徒手写SQL，而且这些徒手写的SQL要经过反复测试和评审。事实上，目前我带过的项目还没有出现过徒手写SQL的情况，因为大家穷尽智力，经过无数次尝试也没能写出对比Hibernate有稳定性能提升的SQL，最后都通过修改表设计、分区、分库分表、业务方妥协或者整体架构的变动来解决性能问题。我的经验告诉我，业务复杂到一定程度的时候，对比徒手写SQL和Hibernate自动生成SQL的效率是一种很愚蠢且没有意义的行为，因为决定效率的不是SQL本身，而是整个系统设计、实施的问题。如果你的数据库架构很烂，再高的SQL水平也写不出能好的性能。