到底应不应该在项目中使用ORM（Object-relational mapping）框架？

来自Martin Fowler的一篇文章，OrmHate。文章的观点是，

关系型数据库和内存对象的相互映射本来就是一个很难的问题： 因为两者属于两种不同的建模方式，而且还要考虑两者的数据一致性（特别是在并发访问／修改的情况下）。 一些开发者对ORM框架有着不实际的期待——他们只想处理（灵活的）内存对象，期待ORM框架能（完美）处理对数据库的操作。 实际上，如果使用了关系型数据库，那么就应该在开发中考虑关系型数据库带来的影响。 如果ORM框架能解决80%的问题，那么使用它就是值得的。 另外，如果不需要双向的映射（bi-directional mapping），或者NoSQL数据库适用于业务场景，可以考虑不用ORM框架。

另一篇文章，ORM Haters Don’t Get It，更细节一些。文章的观点是，

即使不使用现成的ORM框架，也会在项目中创造出一个功能类似ORM框架的东西。 使用ORM还有一些额外的好处，比如方便切换数据库、现成的缓存实现等。 需要防止错误地使用ORM框架（需要熟悉ORM框架，ORM不是一个傻瓜式框架）。 另外ORM框架的session管理一般比较复杂，想要配置好需要一定的经验。

一些想法，

  • 考虑一下NoSQL是否能满足业务需求。
  • 考虑一下轻量级的ORM框架，比如MyBatis，能否满足要求。
  • 使用ORM框架时，考虑显式地使用native query（有时候ORM框架生成的SQL可能并不理想）
  • 在开发过程中打印出ORM框架所执行的SQL语句，确认ORM框架的行为符合性能要求和预期。比如通过执行的SQL语句可以很容易地发现N+1问题。

使用ORM框架（比如Ruby on Rails的ActiveRecord）的另外一个好处是可以快速地进行原型开发。