- 現有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的補充，也說明面向對象不能做完所有的事情。