O/R Mapping
O/R Mapping的全称是Object Relational Mapping主要目的是在传统RDBMS与OO Language之间建映射关系从而使开发人员彻底脱离数据持久这片剪不断理还乱的苦海
关于O/R Mapping或者近来比较热门的O/X Mapping（大家可以参考程序员P）可能需要专门的文章进行详细论述本文的目的主要是对现有方案的优缺点进行简单剖析以及提供一些实践中的参考信息
相比较JEE平台NET下的O/R Mapping可谓没什么历史至今还尚未有经过考验的成熟的可用方案但是随着各大厂商的重视以及开源项目的如火如荼NET O/R Mapping的步伐也开始慢慢跟上使这块本属于JEE的领地加入了新的竞争对手（会不会使更多的开发人员投入NET阵营？J）也让众多疲于在SQL Clause或ADONET中来回奔命的DAL开发人员看到了光明之路
接下来就让我们一起看看在这片比ADONET更广阔的土地上有些什么值得探讨的Solution
Open Source
开源方面一直与NET保持一定距离O/R Mapping更是寥寥无几但就作者的下载试用和源码分析来看个人以为如下的两个解决方案还是有一定参考价值的OPFOJB
有关这两个开源项目的简介大家可以参考程序员P
OPF的全称是Object Persistent Framework
OJB的全称是ObJect Relational Bridge
在实现手法上这两个方案的思路完全不同具有各自的代表性
OPF走的路线有点类似于Typed DataSet或Borland ECO（请参考下面的介绍）实现比较简单提供更多的源码级控制而OJB的实现则类似于Microsoft ObjectSpaces（请参考下面的介绍）采用了配置文件的方式相对就比较复杂了
这两个方案的基本框架如下所示
OPF
从图中不难看出
（）Persistent类扮演了DataSet的角色除了常规的对象数据操作外还可以设定不同对象间的关系（如主从关系集合关系等这一点在Borland ECO所生成的代码中也可略见一二）这也是上文所说提供更多源码级控制的原因所在
（）PersistentSqlDataManager则扮演了DataAdapter的角色通过预先设置的Commands来执行真正的数据库操作在实际撰写的employee data manager中开发人员确实需要提供基本的SQL语句就像在SqlCommond中设置的那样（Borland ECO则更进一步以OCL代替了SQL）
（）ObjectBroker的作用非常重要它是对象与数据间的桥梁RegisterPersistent方法建立了这种虚拟（Object）与现实（RDBMS）间的关系
（）在employee business object的声明中对象属性与数据库字段的对应关系是通过NET Attribute机制体现的所以修改起来还是比较方便的虽然相比配置文件的方式显得不够灵活（请参考OJB的介绍）比如需要重新编译开发人员不得不关注数据库字段等
OJB
从图中不难看出
（）该方案的实现比较复杂但用户需要实际撰写的代码变少了（只需要编写employee business object）这其中的关键就在于引入了配置文件同时由于配置文件的引入我们在hello world application中也不需要调用类似OPF解决方案（请参考上文的OPF类图）中的RegisterObject方法所有这一切（甚至包括数据库连接信息）系统都已了如指掌！
（）该方案中SQL命令通过Criteria类被彻底替代而QueryFacade则充当了Adapter的功能通过PersistenceBroker这一真正的Command与数据库进行通信
（）无论是repositoryxml配置文件还是CriteriaQueryFacade类我们都可以在ObjectSpaces（请参考下面的介绍）中找到类似的实现（难道是巧合？）同时作者个人以为这种方式也更符合O/R Mapping的精神减轻了开发人员的负担！
（）OJB还有一个非常cool的工具repositorygenexe可以用来生成repositoryxml配置文件（同样的源码无偿奉上J）这一点甚至连ObjectSpaces都没能做到（想想那么多字段属性关联映射简直可以让人发疯）！
