作者簡言

對自己的框架確定ORM的實現方案。要求盡量對開發友好，開發簡單明了。

需求

1.自動創建Entity：根據Entity自動創建表，能夠減少開發的工作量。
2.自動DAO：具備Template模板或者類似功能，對簡單的內容能夠以更少的代碼實現。
3.簡單的擴展或者強功能API：簡單擴展，個人傾向支持SQL
4.支持cache：支持各種cache的擴展，包括但不限于java cache，memcache等
5.支持事務處理與控制：在Service層必要支持事務處理功能。

方案

1.Hibernate + HibernateTemplate
2.JPA+Hibernate
3.MyBatis+Mapping 4.JPA+MyBatis
5.JdbcTemplate
6.JPA+Hibernate + JdbcTemplate
7.JdbcTemplate + 改裝

對比

Hibernate + HibernateTemplate

1.自動創建Entity：√
2.自動DAO層實現:√
Hibernate對于Spring來說具有hibernateTemplate，僅僅在配置文件中配置下，并在dao實現中進行注入即可
實現方面，需要自己寫繼承類或者泛型類，不過單一實現起來難度也不高，無需操作session
3.簡單擴展：-
由于沿用Hibernate，擴展采用hibernate方式，比較復雜
4.支持cache：√ 在hibernate層面添加cache
5.支持事務處理與控制：√

JPA+Hibernate

1.自動創建Entity：√
2.自動DAO層實現:√
直接繼承接口
3.簡單擴展:X
不達標，嘗試添加自動化的DAO，比較困難
4.支持cache：√
5.支持事務處理與控制：√

MyBatis+Mapping

1.自動創建Entity：X
復雜，必須使用xml進行配置，在映射回object
2.自動DAO層實現：X
比較復雜，需要繼承接口，之后自己寫xml配置文件的sql，該方面的優勢是如果具有DBA則大優,還有我想吐槽,Mapping本意是降低代碼量,全跑xml什么鬼
3.簡單擴展：-
對應xml編寫，熟悉比較簡單，不熟悉比較復雜
4.支持cache：√
支持cache,但使用的是xml配置,比較適合具備DBA的人員進行使用,純粹開發人員直接代碼進行開發即可
5.支持事務處理與控制:√
支持Spring的@Transactional注解

JPA+MyBatis

1.自動創建Entity:X
2.自動DAO層實現:√
3.簡單擴展:X
4.支持cache:√
5.支持事務處理與控制:√

JdbcTemplate

1.自動創建Entity:X
2.自動DAO層實現:X
需要自己實現自動化,不過已經很簡單了
3.簡單擴展:√
4.支持cache:√
5.支持事務處理與控制:√

JPA+Hibernate + JdbcTemplate

1.自動創建Entity:√
2.自動DAO層實現:√
3.簡單擴展:√
通過JdbcTemplate進行擴展
4.支持cache:√
5.支持事務處理與控制:√

結論

也就是說,如果想要依據目前的需求改裝jdbctemplate,需要實現自動創建entity表和自動DAO實現方面的內容。如果僅僅只是用來進行開發工作，JPA+Hibernate+JdbcTemplate的方案完全滿足使用需求