ef-orm - 支持多數據庫的 ORM 框架
ef-orm
A Simple OR-Mapping framework on multiple databases.
-
使用手冊(中文)
http://geequery.github.io/ef-orm/manual/EF-ORM-user-guide.docx
-
使用示例工程 https://github.com/GeeQuery/ef-orm/tree/master/orm-tutorial
EF-ORM是一個輕量，便捷的Java ORM框架。并且具備若干企業級的應用特性，如分庫分表、JTA事務等。
-
代碼生成插件for eclipse（請在eclipse中Help/Install new software后輸入地址并安裝）http://geequery.github.io/plugins/1.3.x/
特點一
EF的設計的一個主要目的是提高開發效率，減少編碼工作，讓開發者“零配置”“少編碼”的操作數據庫大部分功能。
例如：數據庫查詢條件的傳入問題是所有ORM框架都不能回避的一個問題，所以我經常在想——既然我們可以用向DAO傳入一個Entity來實現插入操作，為什么就不能用同樣的方法來描述一個不以主鍵為條件的update/select/delete操作？為什么DAO的接口參數老是變來變去？為什么很多應用中，自行設計開發類來描述各種業務查詢條件才能傳入DAO？為什么我們不能在數據訪問層上花費更少的時間和精力?
JPA1.0和早期的H框架，其思想是將關系型數據庫抽象為對象池，這極大的限制了本來非常靈活的SQL語句的發揮空間。而本質上，當我們調用某H框架的session.get、session.load、session.delete時，我們是想傳遞一個以對象形式表達的數據庫操作請求。只不過某H框架要求（并且限制）我們將其視作純粹的“單個”對象而已。JPA 2.0為了彌補JPA1.0的不足，才將這種Query的思想引入為框架中的另一套查詢體系——Criteria API。事實上針對單個對象的get/load/persist/save/update/merge/saveOrUpdate API和Criteria API本來就為一體，只不過是歷史的原因被人為割裂成為兩套數據庫操作API罷了。
因此，對于關系型數據庫而言——Entity和Query是一體兩面的事物，所謂Query，可以包含各種復雜的查詢條件，甚至可以作為一個完整的SQL操作請求的描述。為此，EF徹底將Entity和Query綁在了一起。這種思想，使得——
-
開發人員需要編寫的類更少。開發人員無需編寫其他類來描述復雜的SQL查詢條件。也無需編寫代碼將這些查詢條件轉換為SQL/HQL/JPQL。DAO層也不會有老要改來改去的接口和API，幾乎可以做到零編碼。
-
對單個對象進行CRUD的操作API現在和Criteria API合并在一起。Session對象可以直接提供原本要Criteria API才能提供實現的功能。API大大簡化。
-
IQueryableEntity允許你將一個實體直接變化為一個查詢（Query），在很多時候可以用來完成復雜條件下的數據查詢。比如 ‘in (?,?,?)’， ‘Between 1 and 10’之類的條件。 xxQL有著拼裝語句可讀性差、編譯器無法檢查、變更維護困難等問題，但是卻廣受開發人員歡迎。這多少有歷史原因，也有Criteria API設計上過于復雜的因素。兩者一方是極端靈活但維護困難，一方是嚴謹強大而學習和編寫繁瑣，兩邊都是極端。事實上JPA的幾種數據查詢方式存在青黃不接的問題。選擇查詢語言xxQL，項目面臨后續維護困難，跨數據庫移植性差；選擇Criteria API，代碼臃腫，操作繁瑣，很多人望而卻步。EF的設計思想是使人早日擺脫拼裝SQL/HQL/JPQL的困擾，而是用（更精簡易用的）Criteria API來操作數據庫。
-
基于輕量級Criteria API的操作方式，使得對數據庫的變更和重構變得非常輕松，解決了SQL語句多對軟件維護和移植造成產生的不利影響。
-
閱讀推薦：第3、4章
特點二，將SQL的使用發揮到極致，解決SQL拼湊問題、數據庫移植問題
大部分OLTP應用系統到最后都不免要使用SQL/JPQL，然而沒有一個很好的方法解決SQL在多種數據庫下兼容性的問題。 EF-ORM中采用了獨特的SQL解析和改寫技術，能夠主動檢查并確保SQL語句或者SQL片段在各個數據庫上的兼容性。
EF中除了Criteria API以外，可以直接使用“SQL語句”或者“SQL片段”。但是這些SQL語句并不是直接傳送給JDBC驅動的，而是 有著一個數據庫方言層，經過方言層處理的SQL語句，就具備了在當前數據庫上正確操作的能力。這相當于提供了一種能跨數據庫操作的SQL語言。(E-SQL) E-SQL不但解決了異構數據庫的語法問題、函數問題、特殊的寫法問題，還解決了動態SQL問題、綁定變量擴展等特性。 對于各種常用SQL函數和運算符，都可以自動轉換為當前數據庫支持的方言來操作。其函數支持也要多于HQL支持的函數。
-
閱讀推薦：第7、8章
特點三，可能是業界最快的ORM框架.
得益于ASM的動態代碼生成技術，部分耗時操作通過動態代碼固化為硬編碼實現，EF-ORM的大部分操作性能要超過已知的其他框架。 實際性能測試表明，EF的大部分操作都要快于Hiberante和MyBatis， 部分操作速度甚至數十倍于上述框架。 EF在極限插入模式下，甚至刷新了每秒10萬條寫入的記錄。遠遠超過了其他框架。
一個初步的性能測試：
測試代碼：http://geequery.github.io/ef-orm/manual/performance-test.rar 測試報告：http://geequery.github.io/ef-orm/manual/performance-compare.docx
-
閱讀推薦：第9、17章
特點四，分庫分表
開發過程中參照了Hibernate Shards、Alibaba TDDL、Cobar等框架，也是基于詞法分析器來提取SQL參數，并計算路由。 能支持分庫維度含糊等場景下的分庫分表。以及包括多庫多表下的 order by , distinct, group by, having等操作。
-
閱讀推薦：第10章
特點五，常用DDL操作的封裝
從數據庫元數據訪問，到建表，創建約束，創建sequence等各種DDL操作進行了封裝，用戶無需編寫各種SQL，可以直接通過API操作數據庫結構。 尤其是ALTER TABLE等修改數據庫的語句，各種不同的RDBMS都有較大語法差異。
特點六、解決各種跨RDBMS的移植問題
1、DML操作、自增值處理與返回、查詢這些不同數據庫操作差異很大的東西，都了統一的封裝。 2、DDL操作、建表、刪表、trunacte，Sequence創建和TABLE模擬Sequence等，都做了支持。 3、對SQL語法操作和函數的改寫與支持。
其他特性
輕量
該框架對應用環境、連接池、 是否為J2EE應用等沒有特殊要求。可以和EJB集成，也可與Spring集成，也可以單獨使用。整個框架只有兩個JAR包，模塊和功能都較為輕量。
依賴少
整個框架只有三個jar庫。間接依賴僅有commons-lang, slf4j等7個通用庫，作為一個ORM框架，對第三方依賴極小。
簡單直接的API
框架的API設計直接面向數據庫操作，不繞彎子，開發者只需要數據庫基本知識，不必學習大量新的操作概念即可使用API完成各種DDL/DML操作。 最大限度利用編譯器減少編碼錯誤的可能性 API設計和元數據模型（meta-model）的使用，使得常規的數據庫查詢都可以直接通過Criteria API來完成，無需使用任何JPQL/HQL/SQL。可以讓避免用戶犯一些語法、拼寫等錯誤。
JPA2規范兼容
使用JPA 2.0規范的標準注解方式來定義和操作對象。（但整個ORM不是完整的JPA兼容實現）
更高的性能
依賴于ASM等靜態字節碼技術而不是CGlib，使得改善了代理性能；依賴于動態反射框架，內部數據處理上的開銷幾乎可以忽略。操作性能接近JDBC水平。對比某H開頭的框架，在寫入操作上大約領先30%，在大量數據讀取上領先50%以上。
更多的性能調優手段
debug模式下提供了大量性能日志，幫您分析性能瓶頸所在。同時每個查詢都可以針對batch、fetchSize、maxResult、緩存、級聯操作類型等進行調整和開關，可以將性能調到最優。
可在主流數據庫之間任意切換
支持Oracle、MySQL、Postgres、MSSQL、GBase、SQLite、HSQL、Derby等數據庫。除了API方式下的操作能兼容各個數據庫之外，就連SQL的本地化查詢也能使之兼容。
JMX動態調節
可以用JMX查看框架運行統計。框架的debug開關和其他參數都可以使用JMX動態調整。
動態表支持
表結構元數據的API也向用戶開放，同時支持在使用過程中，靈活調整映射關系，因此用戶可以用API動態的創建表結構的模型，從而實現各種動態類型和表的映射（例如POJO中包含一個Map，用于映射各種動態擴展的字段）
企業級特性支持
SQL分析，性能統計，分庫分表，Oracle RAC支持，讀寫分離支持.
官方網站：http://www.baiduhome.net/lib/view/home/1455511399073