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.