现有ORM框架或ORM相关框架存在的问题

最新推荐文章于 2024-09-15 21:38:50 发布

abckingaa

最新推荐文章于 2024-09-15 21:38:50 发布

阅读量4.7k

点赞数 1

分类专栏： Java ORM

本文链接：https://blog.csdn.net/abckingaa/article/details/84557336

版权

ORM 同时被 2 个专栏收录

209 篇文章 0 订阅

订阅专栏

Java

173 篇文章 3 订阅

订阅专栏

现有ORM 框架或ORM 相关框架主要有Hibernate，
Mybatis。这两个框架本来是为了解决直接用JDBC 操
作数据库带来的烦锁重复工作，但它们却引起了其他的问题。
有人报怨Mybatis，很简单的操作，都要写sql语句(虽然国内出了些第三方插件,但要整合到mybatis也不是简单的事.)；
有人报怨当用户要用自定义sql的方式时Hibernate是如何的难用，要想熟悉Hibernate是如何的困难。
而Mybatis的流行，也印证了贴近原生sql的方式很受欢迎(即使最近几年NOSQL产品很火爆)。
除此之外，还有些问题，是它们二者都具有的，如编码复杂度为O（n）。

现有ORM框架或ORM相关框架存在的问题，主要参考Hibernate和Mybatis。
1)   对于每个实体，需要写一个dao接口文件。编码复杂度C(n)=O(n)，即会随实体的增长，编码量呈线性增长。当n较大时，会增加许多人力物力消耗。
2)   实体Javabean与DB表的map映射文件太多；或者，实体Javabean文件注解用得太泛滥，太多注解难以记忆，增加开发人员负担。Mybatis中实体对应的mapper文件，代码太多，虽然可以自动生成，但阅读性太差。编写和调试sql语句需要大量时间，降低开发效率。
3)   实体操作默认的条件，一般以id作为条件，但开发时，一般不会提前知道id；若用其它条件作为查询等，需要在接口文件新定义方法。如一个实体有10个字段，2个字段组合一个查询方法，则有 =45个查询方法；若算上3个字段，4个字段的组合，则更多。
4)   接口文件定义好后，若后期发现定义的方法不能满足需求，需要定义新的方法，又要修改接口文件；若是系统已经上线，还要需要重新开发、测试、发布等。
5)   当一个表新增一个字段，删除一个字段，或修改一个字段时，Mybatis需要修改mapper映射文件，几乎其中的每个方法都要修改。修改字段，Mybatis在编译期不能自动发现错误。Hibernate通过xml文件或有注解的Javabean文件，同步DB的表结构时，也不能实现删除和更新。更新时，它是忽略原来的字段，然后新增一个字段，除非删除了表，重新再建一次。要是DB的表已保存了数据，不能删除，还是要手动去更改数据库。
6)   Hibernate想让ORM框架做完DB所有的事情，反而使框架变得太复杂，不易于使用。Hibernate的ORM模型不能查询一部分数据，即使用户没有使用到，也会将所有关联的数据都查询出来。
7)   Hibernate的概念太复杂，学习成本高，更新会先查询再更新，n+1问题。Mybatis即使进行单表的Suid操作也需要人工写sql或生成sql文件，需要维护的sql太多。
8)   需要写很多的判断字段是否为空（null) ，是否是空字符串的语句；开发人员需要承担太多类似的重复，乏味的编程工作。
9)   对于一些复杂的操作，Criteria类查询风格与SQL原来的语法风格相差甚远，相当于要学一门新的SQL操作语言。

软件开发中，对数据库的访问操作，约80%的工作
可以由简单的面向对象操作方式完成，只有约20%的工
作才需要复杂的SQL 语句完成。当一个ORM 框架为了
使这20%的工作量也可以用面向对象的方式实现时，这
个ORM 框架的复杂度就会随着完成这20%的比例而急
剧上升，但还是避免不了用户用自定义SQL 语句操作
数据库的情况发生。也就是说，即使一个ORM 框架可
以100%的实现面向对象方式操作数据库，它还是需要
提供直接用原生SQL 语句操作数据库的接口。毕竟，
有时用户为了提高性能，需要这样操作( 有Hibernate,
但Mybatis还是存在,就说明了自定义SQL是有需求的)。
另外，面向切面编程AOP 被视为面向对象编程OOP 的补充，
也说明面向对象不能做完所有的事情。

Bee与Hibernate,Mybatis的区别,参考以下文章,进行对比: