http://www.cnblogs.com/format/category/2186.html
ObjectSpace 基础
摘要：介绍O/R映射，和ObjectSpace相关的基础知识
一、 O/R Mapping框架
1、 O/R Mapping介绍
在我们开发应该程序的时候，总是要跟很多数据打交道，为这些处理主要是围绕这数据的查询于存储。对于要处理高可靠性和一直性数据的时候我们一般采用数据库，例如：SQL Server。我们都知道SQL Server等数据库都是建立在关系模型之上的，而现在我们大部分所使用的语言（C#和VB.NET，Java）都是面向对象的，这就产出了矛盾，在O/R Mapping框架出现前我们处理数据存储都不是用完全面向对象的方法，而将就数据库用半过程型（写一个保存数据的方法或是通过一个控制类来组合对象）的方法来存取数据。就拿SQL Server数据库带的例子NorthWind来说明，其中有Customer、Order、OrderDetail表，在.net下我们会用DataSet来存取他们，并加入约束和关系，从面向对象方法来做应该是这样的Customer对于多个Order，那么Order应该是Customer对象的一个属性，这个属性就是Order对象，而不只是Order表中储存的一个CustomerID，如果用DataSet来做就需要编写Sql语句或者是存储过程来查询实现，这就需要额外的控制类来完成，实际上ObjectSpace就是用来完成这一过程的框架。
在以往很多失败的项目其原因就是在数据访问上，如果我们有几百个对象，有几百张表可以想像这样的系统数据访问是多么庞大，ObjectSpace的出现可以说是一个革命，我们只需要使用映射工具生成映射稳定，然后剩下的工作就由ObjectSpace来完成，而且数据库设计的地位不再象原来那么神圣了，基本上我们做完分析后，数据库的表就可以根据分析出来的实体对象得到。
1、 O/R Mapping理论
O/R Mapping就是Object-Relational Mapping（对象－关系映射），另外还有个缩写是ORM的Object Role Modeling（对象角色建模）这个和我们的ObjectSpace没有什么关系。
正如前面所说，O/R Mapping就是要解决关系模型和对象模型的矛盾，在C#之类完全面向对象的环境中不去处理这一矛盾，把精力大部分投入到对象的分析和设计中。
图1 不同数据模型的比较（本图片来源于微软网站的Getting Started with ObjectSpaces）
对象模型理论经过几年的发展已经趋于成熟，而且其优势也不断体现。面向对象建模和编程很接近我们的现实生活，而且其优势还在于软件开发过程中适应不断的需求变化。在面向对象编程的时候很显然我们建立的对象是放在计算机内存之中，如果关闭计算机那么我们的对象就不存在了，对象的永久性（也就是长久保存对象）是我们一直的期望，在O/R Mapping出现前我们设计程序不得不花费大量的精力和时间构建我们的Data Access Layer (DAL数据存取层)，如果项目规模比较大的时候可想而知这个DAL层的复杂程度，例如微软的Duwamish 7.0中就在这上面用了很多DataSet和DataTable来构建，相当烦琐（当儿也是DAL经典的解决方案）。
现在很多对象模型的数据库已经出现，但其还很不成熟，在现阶段我们不得不继续使用关系数据库来保存我们的信息，O/R Mapping让我们以简单快捷地完成对象到关系的转换，使我们内存中的对象在关系数据库中“永恒”。
我估计很有可能当对象数据库技术成熟的时候我们的O/R Mapping就将消失，ObjectSpace等等这方面的东西都只是这一时期的过渡产品。
1、 O/R Mapping的优劣
在前不久一个国外的技术论坛对O/R Mapping进行激励争论，有人把这个东西贬的一文不值，有人有认为这是一场革命。我们用ObjectSpace来比较下O/R Mapping的优劣：
下面是ADO.NET和ObjectSpaces的一个比较
| 技术 | 特点 | 什么时候需要使用 |
| DataSet and DataReaders in ADO.NET. |
|
|
| ObjectSpaces |
|
|
很明显那些贬O/R Mapping的人主要抓住的就是它的性能，可以想像我们保存的对象集合(Collection)肯定要比DataTable耗费内存，和处理更多运算。有人做个测试（CSDN上的一个帖子）：有7000多条记录的数据表中,GetObjects需要20多秒，而Find只要2秒，使用SqlDataAdapter.Fill方法则不到1秒。我个人做过粗略的测试大概2000条记录，用DataSet和ObjectSpace在界面上几乎感觉不出什么差别。
我个人的观点是：在现阶段赞同O/R Mapping，认为这会大幅度提高我们的软件开发效率，而且现在计算机的性能一般都还可以，所以几个毫秒的差别不会给使用造成很大的问题。而且对象数据库是我们的目标，O/R Mapping也许只是过渡性的东西，说不定再过几十年看历史书也找不到这个概念，我们不应把全部希望放在这个东西上，它毕竟只是一个辅助性的框架，当然也没有必要使劲贬低它，只要它能带给我们好处我认为它就是好的。
2、 一些O/R Mapping框架
这个框架的概念最早出现于Java平台，现在Java平台下用好几种这类工具例如：Hibernate、JDO等等都是开源免费的，这我就不叙述Java下的工具，我们主要说说.NET下的。
NHibernate（免费）
http://sourceforge.net/projects/nhibernate
NHibernate 是模拟java hibernate 的.net实现，当前在.net社区中，对其寄于厚望。这个东西最近推出了新版本，不过我从来没有用过。
XPO（eXpress Persistent Objects）
这个是Developer Express Inc. 公司的产品，这个公司有个很出名的控件XtraGrid。XPO运用了对象缓存池技术其在读写数据库速度上有了很大提高，据说和DataSet不相上下了。不过XPO最大的缺点就是映射文档，他不像ObjectSpace用XML文档来保存映射信息，XPO是用在类或者方法前面加特性（Attribute）来完成映射，如果数据库的很多，实际上用这东西不比写SQL语句好多少，不像ObjectSpace的映射文档点点鼠标就可以完成了。
WilsonORMapper
这个是一个叫Wilson的外国MVP写的，应该是属于比较早的O/R Mapping工具，这东西注册需要50美元。从易用性和其他方面这个工具都还是不错的，而且支持很多种数据库，不像ObjectSpace只支持SQL Server。但这个工具不能夸数据库的表做映射，期望以后的版本会有所改进。
目前.NET主要映射框架（工具）就是这几个了，其他的我都还不了解。
注：其中一些资料来源于 CSDN 论坛上对 O/R Mapping 讨论的帖子。
这里是KaneBoy在Blog上发表项目心得的一段话:
| 这个项目我使用了DevExpress的ORM产品：XPO，它是一个可以完全对开发人员屏蔽数据库操作的透明持久层，而并非常见的在Entity与数据库Table之间定义映射关系后自动进行存取数据操作的ORM。这就意味着，在开发过程中，我可以完全不用去管建表、建字段、取数据之类的所有的数据库相关的操作。根据我的估计，它大约节约了我40%的写代码时间。我承认XPO有这样或者那样的缺点，但是，它最重要的优点，提高开发速度，完完全全的吸引了我。 |
可以看出ORM的优势所在,我在我们的项目中花了点时间对XPO的读取速度做了个只能说初略的测试.
我做的测试的数据库(SQL Server)服务器和工作机是分开的,在公司 100M 的局域网环境下工作.
测试环境:
|
| 硬件配置 | 备注 |
| 数据库服务器 | P4 2.4 / 512M 内存Windows 2003 Server | 塔式服务器 |
| 工作计算机 | P4 1.8/ 512M 内存 Windows XP | 笔记本电脑 |
我用一张有42个字段的表,这个表和其他20多张表有关系映射(应该是比较有代表性了),在测试前我用循环语句(是用XPO)向数据库写了1万条记录,大概花了4到5分钟,但这不是我们测试的重点(一般很少有情况会一次写入那么多记录),最后我删除了97%的数据,留下来300条做读取测试,我把这些记录读取后放到一个DataGrid中. 
测试结果:
| 测试读取数据量 | 起始环境 | 用时 (秒为单位,保留两位小数) | 备注 |
| 读取1万条记录 | 数据库之前已有读取,程序第一次启动 | 17.68 |
|
| 读取300条记录 | 数据之前没有读取, 程序第一次启动 | 2.34 |
|
| 读取300条记录 | 数据之前没有读取, 程序第一次启动 | 2.56 |
|
| 读取300条记录 | 数据库之前已有读取,程序第一次启动 | 1.19 |
|
| 读取300条记录 | 数据库之前已有读取,程序第一次启动 | 1.48 |
|
| 读取300条记录 | 数据库之前已有读取,程序已经启动 | 0.22 | 在关闭测试窗口后(但没有推出测试程序),再次打开测试窗体 |
| 读取300条记录 | 数据库之前已有读取,程序已经启动 | 0.18 |
|
从”任务管理器”进程管理的显示上看这个测试程序在读取记录前占用 24M 左右的内存,在读取300条记录后占用的内存在 34M 到 58M 之间.就是关闭测试窗体,但不推出程序也要占那么多,这是因为XPO有个对象缓存池,有了这个缓存XPO的工作效率相当高,在实际使用的感觉中和DataSet差不多,但也不像XPO宣传的那样在某些情况下比DataSet还快,我个人认为DataSet的效率应该比XPO高那么一点点,但差别甚微是是主观感觉不出来的(我具体没有做个测试).
从上面的结果可以看出读取数据所花费的时间和SQL Server的缓存有很大关系,当然和网络环境其他因素也有关.XPO的表现令我感到满意,现在可以大胆的用XPO做项目了.ORM框架的效率问题一直是人们争论的中心,我个人认为在项目要求不是很严格的情况(对数据实时性要求)下完全可以用XPO,这是成倍提高开发效率的好东西.
附:
我测试用的代码:
private
void
btnStart_Click(
object
sender, System.EventArgs e) 
{ 
DateTime start=DateTime.Now; this.labStart.Text+=start.ToString(); Manager dm=new Manager();//在实例化对象的时候构造函数用XPO读取300条记录 this.dataGrid1.DataSource=dm.Drugs;//填充到DataGrid赋值 DateTime end=DateTime.Now; this.labEnd.Text+=end.ToString(); TimeSpan js=end-start; this.labTotal.Text+=js.TotalSeconds.ToString(); 
}
294
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
