Ø 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点更为严重的后果;
说了些不足,其实也无须过于担心,毕竟,没有十全十美的解决方案,怎么取舍就看你自己的决定了。
本章最后,作者给出了一个自己的总结,可供您参考一二。在所有的分析完毕之后,作者也试图结合自己的实践提供“我的方案(撰写中)”,希望能给各位读者带来帮助。