iBATIS框架源碼剖析

iBATIS一詞來源於“internet”和“abatis”的組合，是一個由Clinton Begin在2001年發起的開放源代碼項目。於2010年6月16號被Google託管，改名爲MyBatis，是一個基於SQL映射支持Java和·NET的持久層框架，ORM之一。 關於ORM：在現代數據化、信息化的各種項目、軟件開發中，絕大多數Business models都會涉及到對關係型數據庫中的數據進行操作(CRUD)；關係數據模型則基於數學原理，特別是集合論的原理，這些原理都能在數學理論上得到完全的證明。而對象模型基於程序設計的一些原則，類同於一種解決問題的工具，並沒有得到公理或數學理論的支持。面向對象設計的目標是通過把一個業務過程分解成具有狀態和行爲的對象來進行建模的業務過程，而關係數據庫的設計目標是規範化數據以消除數據冗餘度，兩種不同的理論基礎導致對象模型與關係數據模型之間的阻抗不匹配。關係數據庫不支持諸如類、繼承、封裝和多態等面向對象的概念。ORM是在對象與數據庫之間進行映射的一種技術，對象間的關係、類及其屬性以某種方式映射爲關係數據庫中的數據庫關係、表和字段。 ORM優點：可使用Object Oriented思維操作RDBMS中的數據，簡化程序員開發工作，也在很大程度上加強了SQL安全性； ORM缺點：處理複雜查詢語句會比較麻煩，比如在OLAP類型的業務模型中；另外相對於裸SQL，性能上也會低很多。 如何選擇？這是個仁見智見的話題，一般而言小型項目、或者特別在乎性能建議裸SQL；大型項目，尤其是多個開發Team合作且水平良莠不齊時，可以考慮使用ORM。以下摘自stackoverflow： I'd say that if you aren't dealing with objects there's little point in using an ORM. If your relational tables/columns map 1:1 with objects/attributes, there's not much point in using an ORM. If your objects don't have any 1:1, 1:m or m:n relationships with other objects, there's not much point in using an ORM. If you have complex, hand-tuned SQL, there's not much point in using an ORM. If you've decided that your database will have stored procedures as its interface, there's not much point in using an ORM. If you have a complex legacy schema that can't be refactored, there's not much point in using an ORM. So here's the converse: If you have a solid object model, with relationships between objects that are 1:1, 1:m, and m:n, don't have stored procedures, and like the dynamic SQL that an ORM solution will give you, by all means use an ORM.