.Net下的数据访问层技术的详细介绍

.Net下的数据访问层技术的详细介绍

u O/R Mapping

O/R Mapping的全称是：Object Relational Mapping，主要目的是在传统RDBMS与OO Language之间建映射关系，从而使开发人员彻底脱离数据持久这片剪不断理还乱的苦海。

关于O/R Mapping或者近来比较热门的O/X Mapping（大家可以参考“程序员，2004.01，P86”），可能需要专门的文章进行详细论述，本文的目的主要是对现有方案的优缺点进行简单剖析以及提供一些实践中的参考信息。

相比较J2EE平台，.NET下的O/R Mapping可谓没什么历史，至今还尚未有经过考验的成熟的可用方案。但是，随着各大厂商的重视以及开源项目的如火如荼，.NET O/R Mapping的步伐也开始慢慢跟上，使这块本属于J2EE的领地加入了新的竞争对手（会不会使更多的开发人员投入.NET阵营？J），也让众多疲于在SQL Clause或ADO.NET中来回奔命的DAL开发人员看到了“光明之路”。

接下来，就让我们一起看看在这片比ADO.NET更广阔的土地上有些什么值得探讨的Solution。

Ø Open Source

开源方面一直与.NET保持一定距离，O/R Mapping更是寥寥无几，但就作者的下载试用和源码分析来看，个人以为如下的两个解决方案还是有一定参考价值的：OPF，OJB。

有关这两个开源项目的简介，大家可以参考“程序员，2004.01，P13”。

OPF的全称是：Object Persistent Framework。

OJB的全称是：ObJect Relational Bridge。

在实现手法上，这两个方案的思路完全不同，具有各自的代表性。

OPF走的路线有点类似于Typed DataSet或Borland ECO（请参考下面的介绍），实现比较简单，提供更多的源码级控制；而OJB的实现则类似于Microsoft ObjectSpaces（请参考下面的介绍），采用了配置文件的方式，相对就比较复杂了。

这两个方案的基本框架如下所示：

OPF：

从图中不难看出：

（1） Persistent类扮演了DataSet的角色，除了常规的对象数据操作外，还可以设定不同对象间的关系（如主从关系，集合关系等，这一点在Borland ECO所生成的代码中也可略见一二），这也是上文所说“提供更多源码级控制”的原因所在；

（2） PersistentSqlDataManager则扮演了DataAdapter的角色，通过预先设置的Commands来执行真正的数据库操作；在实际撰写的employee data manager中，开发人员确实需要提供基本的SQL语句，就像在SqlCommond中设置的那样（Borland ECO则更进一步，以OCL代替了SQL）；

（3） ObjectBroker的作用非常重要，它是对象与数据间的桥梁，RegisterPersistent方法建立了这种虚拟（Object）与现实（RDBMS）间的关系；

（4） 在employee business object的声明中，对象属性与数据库字段的对应关系是通过.NET Attribute机制体现的，所以修改起来还是比较方便的，虽然相比配置文件的方式显得不够灵活（请参考OJB的介绍）,比如：需要重新编译，开发人员不得不关注数据库字段等。

OJB：

从图中不难看出：

（1） 该方案的实现比较复杂，但用户需要实际撰写的代码变少了（只需要编写employee business object），这其中的关键就在于引入了配置文件；同时，由于配置文件的引入，我们在hello world application中也不需要调用类似OPF解决方案（请参考上文的OPF类图）中的RegisterObject方法，所有这一切（甚至包括数据库连接信息），系统都已了如指掌！

（2） 该方案中，SQL命令通过Criteria类被彻底替代，而QueryFacade则充当了Adapter的功能，通过PersistenceBroker这一真正的Command与数据库进行通信；

（3） 无论是repository.xml配置文件，还是Criteria、QueryFacade类，我们都可以在ObjectSpaces（请参考下面的介绍）中找到类似的实现（难道是巧合？），同时，作者个人以为，这种方式也更符合O/R Mapping的精神，减轻了开发人员的负担！

（4） OJB还有一个非常cool的工具“repositorygen.exe”，可以用来生成repository.xml配置文件（同样的，源码无偿奉上J），这一点，甚至连ObjectSpaces都没能做到（想想那么多字段、属性、关联、映射，简直可以让人发疯J）！