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