一 、ORM 框架是为了解决什么问题而出现的呢？
面向对象建模和编程经过这么多年的发展已经相当成熟，其优势在于能够适应软件开发过程中的不断变化的需求。在面向对象编程的时候很显然我们建立的对象是放在计算机内存之中，如果关闭计算机那么我们的对象就不存在了，对象的永久性（也就是长久保存对象）是我们一直的期望。在O/R Mapping出现前我们设计程序不得不花费大量的精力和时间构建我们的Data Access Layer (DAL数据存取层)，如果项目规模比较大的时候可想而知这个DAL层的复杂程度，涉及到异构数据库那就更加复杂。
二、ORM 框架 的出现是为了解决两个问题：
1. 数据库无关性：平滑迁移数据库和异构数据库；
2. 实体对象的持久性：关系数据库的数据与对象的对应关系。
从这里就可以初步看出，架构至少有两个层次：
1. 数据库存取层Database Access Layer作为核心层，实现数据库无关性；
2. 实体对象映射层 ObjectMapping Layer 作为应用层实现数据到实体对象的映射，该层依赖于核心层。
1.数据库存取核心层是独立通用处于最底层的实现，可以直接拿出来使用的，必须保持高效和安全，主要的功能如下：
* 规范数据库操作，构造 Database 工厂模式（可拓展性），形成数据库操作类 【微软的 Data Access Application Block 】
* 规范 SQL 语句，解决不同的数据库之间的 SQL 语句的差异【最简单的方式方式就是在程序中以SQL语句Id的形式调用SQL语句，将SQL语句集中于一个文件。iBatis 的 DataMapper 采用类似机制，不过它采用的是XML格式，格式的冗余数据降低了加载的效率，在保存加载机制上不够灵活，至少该让用户选择保存为不同的格式；iBatis DataMapper 另一个问题就是将 ObjectMapping 也包含其中，层次不分明，降低可复用性，】。
2.实体对象映射层考虑的问题就多了：
* 简单实体对象属性的映射
* Collection对象属性的映射，如实体对象购物车的物品清单就是一个Collection对象属性，收录了该购物车中的所有的物品。
* 实体对象 MetaData 的考虑，
* 业务规则，约束的考虑等等。。。
这里实体对象映射层是效率最低的一个层次，原因在于映射操作：将实体对象变为数据库数据，数据库数据变为实体对象，而正是这个映射操作使得运行速度大大降低，内存占用大大的增加。如果将所有的实体数据不分青红皂白全部对象化，那么即使是采用Cache（是以牺牲内存为代价的）和分页机制（一次不要取个万把千条数据的，客户也看不过来，一次百来条数据就差不多了，这样就减少了内存的占用和映射操作的时间），但是，当系统面临逐渐增加的并发访问数量面前，系统的性能恶化相当厉害。企业级应用，也许是特指那些愿意花高价购买IBM RS/6000之流的机器的冤大头们吧。但是对于我们这些搞技术的，则是该将注意力集中在如何充分挖掘机器的每一分潜力上才是，相信对于每一个量入为出的企业来说，它应该是欣赏的。这个目前也没有想到什么好的办法，对于减少内存开销，有个建议就是在设计时候，尽可能的延迟加载时间（如实体对象购物车的物品清单，实际数据的加载只有当访问该属性的时候才加载，而对于大的备注,Blob类型的属性也可以采取类似的机制）。实际上，大多数用户的操作都是在浏览，因此对于浏览数据的形式，可以绕过ObjectMapping层，通过数据库存取层返回dataset直接操作，这样也能进一步提高速度和降低内存的消耗。