Ø ** Microsoft ObjectSpaces **
这是一个在几年前就让众多 .NET guy 伸长脖子激动不已的技术。就作者来说，那个时候，只要一提起这个话题，一般都是在 J2EE guy 的嘲笑声中悻悻而归，恨不能自己也搞个 ENB （相对 EJB ）或者 NCMP （相对 CMP ）什么的。
终于，我们可以在 ** .NET Framework 1.2 ** （可在 VS.NET 2004Whidbey 或 Yukon 中找到，目前都是 Beta 版本）中一睹其“芳容”了 J 。
首先，让我们看看用 ObjectSpaces 写出的代码是什么样子（依然使用上面的 employee 例子）：
_ // _ _ 初始化 _ _ ObjectSpace _
SqlConnection conn = new SqlConnection("Data Source=localhost;
Integrated Security=SSPI; Database=Northwind");
ObjectSpace os = new ObjectSpace("map.xml", conn);
_ // _ _ 根据 _ _ EmployeeID _ _ 返回其 _ _ Title _
Employee oEmp = (Employee)os. GetObject (
new ObjectQuery (typeof(Employee), "ID = 1"));
_ // _ _ 注意：实际字段名为： EmployeeID _
string strTitle = oEmp.Title;
……
_ // _ _ 根据 _ _ City _ _ 返回所有符合条件的 _ _ Employee _
ObjectSet oSet = os. GetObjectSet (
new ObjectQuery (typeof(Employee), "City = '”Seattle'"));
_ // _ _ 注意：返回的不是 DataTable _ _ ，而是对象集合 _
foreach (Employee oEmp in oSet)
{
…… // _ 注意：在这里可以对 oEmp _ _ 做任何操作 _
｝
针对上面第二段代码，还有一种解决方案，就是以 ObjectReader 替代 ObjectSet ，这其中所包含的差异，类似于 ADO.NET 1.0 （包含 ObjectSpacesd 的 ADO.NET 又称为 ADO.NET 2.0 ）中的 DataSet / DataTable 与 DataReader 间的不同（不得不佩服 Microsoft 在前后一致性上表现出的老谋深算 J ）。
仔细分析上面的代码，就可以发现它和前面讨论的 OJB 有惊人的相似点（ OJB 中作者只画了基本类图，但足可看出这种思想上的接近）！
例如： ObjectSpace 类基本上提供了 OJB 中的 QueryFacade 功能； ObjectQuery 类基本上提供了 OJB 中的 Criteria 功能；同时，两种解决方案又不约而同的使用了配置文件来存储 O/R Mapping 信息；而应用程序一般也就通过这 2 个类进行数据操作，非常方便。稍微有些区别的可能是在数据返回格式上（这一点， ObjectSpaces 考虑得更细致，可以参考上面的代码），但这已经对实际的代码实现影响不大了。
如果将 ObjectSpaces 下的调用代码与前面给出的那段在 ADO.NET 下撰写的代码作个比较，不难看出， ObjectSpaces 给出的代码更易阅读和理解，就算不熟悉 ADO.NET 整体架构的开发人员，也可轻松上手（唯一涉及 RDBMS 的代码只有建立数据库连接时需要）。对于已经熟悉 ADO.NET 或曾接触过 O/R Mapping （如： J2EE 下的 Hibernate ）的朋友来说，真可谓小菜一碟！
从 .NET Framework 1.2 文档中可以知道， ObjectSpaces 总共提供了 3 个命名空间，整体结构非常清晰：
System.Data.ObjectSpaces
System.Data.ObjectSpaces.Query
System.Data.ObjectSpaces.Schema
ObjectSpaces 、 Query 已在上面的代码中见识过，从名字中可以猜出，它们主要负责向外提供基本访问接口（如查询、增 / 删 / 改等）和解析各种查询条件（如对象过滤等）， Schema 命名空间则主要用来操作 O/R Mapping 配置文件，并为其它两个命名空间中的类提供服务。
在 ObjectSpaces 中， O/R Mapping 配置文件主要指 ** map.xml ** ，这个文件的名字是可以随意更换的，比较类似 OJB 中的 repository.xml 。另外两个分别描述数据库结构和对象结构的配置文件也非常重要： RSD.xml （ Relational Schema Definition ）， OSD.xml （ Object Schema Definition ）。可以将它们理解为 Typed DataSet 中的 XSD 文件，没有它们，所有的数据 / 对象 Mapping 和 Validation 都将是“非法”的 J ！
本文中，作者不准备对 ObjectSpaces 来个深度探索，也不会提供什么 Sample 说明其优越性，这方面， .NET Framework SDK 早已为大家提供了丰富套餐。
作者只是希望，如果从 DAL 的角度来分析， ObjectSpaces 技术能为我们带来什么，是否意味着从此告别 DataReader / DataSet ，抑或为开发人员带来了新的烦恼？
好处不多说，仅举数例即可明了：
（1） ObjectSpaces 全部采用对象方式访问数据，大大缓解了很多开发人员的 SQL （或者说 RDBMS ）恐惧症；
（2） 对于比较简单的数据库结构变化，只需要修改配置文件即可，无需重新编译代码（较之 OPF 中将映射关系以 .NET Attribute 方式封装于代码中，显得更加灵活、方便）；
（3） 对于比较复杂的数据库结构变化，由于只涉及对象操作，所以修改的工作也要比以前简单许多；
（4） 采用了 O/R Mapping 配置文件后，数据库设计与 DAL 开发可以分别进行，相互的影响也降到了最低点；
不足则是我们更须关注的话题：
（1） 目前版本 不支持中文 （永远的话题 J ）查询，不爽！
（2） 当前版本 仅支持 ** SQL Server 2000 ** ** 以上 ** 版本的数据库系统，弱（这是个很耐人寻味的限制，有兴趣的读者不妨想想到底是什么原因）！
_ （ 1 _ _ 、 2 _ _ 引自 .NET Framework SDK Document _ _ ，就这两点已排除了很多跃跃欲试的朋友。而作者参与的 .NET _ _ 项目虽不受 1 _ _ 影响，但由于经常使用 Oracle _ _ ，就不得不暂时忍痛割爱了 _ _ J _ _ ） _
_ _
（3） ** 性能问题 ** 。虽然 ObjectSpaces 也提供了类似 DataReader 的功能（ ObjectReader ），但毕竟需要进行一次数据强类型填充，无论如何会有损失，如果返回数据量变大，将是一个不得不考虑的问题；
（4） ** 还是性能问题 ** 。 map.xml 是个好东东，但如何优化对它的访问以及进行正确的 Validation （基于 RSD.xml 、 OSD.xml ）毕竟需要时间，甚至在某些时候（数据库结构比较复杂），这会造成比第 3 点更为严重的后果；
说了些不足，其实也无须过于担心，毕竟，没有十全十美的解决方案，怎么取舍就看你自己的决定了。
本章最后，作者给出了一个自己的总结，可供您参考一二。在所有的分析完毕之后，作者也试图结合自己的实践提供“我的方案（撰写中）”，希望能给各位读者带来帮助。
** 作者简介： ** ** **
“ 本文作者张雪峰 是 毕博全球开发中心 的高级开发工程师。他目前在中国上海 毕博全球开发中心 Core/EAI 部门工作，从事 .NET 技术的研究以及相关项目的开发。可以通过 [email protected] 与他联系。 ”