剖析 .Net 下的数据访问层技术（四）
2024-07-10 13:05:06
供稿：网友
ø 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点更为严重的后果；
说了些不足，其实也无须过于担心，毕竟，没有十全十美的解决方案，怎么取舍就看你自己的决定了。
本章最后，作者给出了一个自己的总结，可供您参考一二。在所有的分析完毕之后，作者也试图结合自己的实践提供“我的方案（撰写中）”，希望能给各位读者带来帮助。
