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