当前页面: 开发资料首页 → J2SE 专题 → 剖析.Net下的数据访问层技术(4)

剖析.Net下的数据访问层技术(4)

摘要: 剖析.Net下的数据访问层技术(4)

<table cellSpacing=0 cellPadding=0 border=0 class="zh114" align="right"> <tr> <td > </td> </tr> </table>
　　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点更为严重的后果；