Object

Object（精选3篇）

Object 篇1

0 引言

冷换设备是一种实现物料之间热量传递的设备，是炼油化工生产中重要的传热设备，需承受高温高压，属于国家和地方技术质量监督局监管的特种设备，要求严格管理，同时也属于经常需要维修的易损设备。然而，炼油化工企业各装置设计生产标准各异，冷换设备型号规格五花八门，导致各冷换设备的整体结构与技术参数大相径庭，给设备管理与维修带来诸多不便。因此，亟需建立完备的冷换设备使用维修文档资料库，技术参数数据库和设备装配图库，以及快捷方便的设备管理系统网络平台。

目前国内外没有专门针对冷换设备的管理信息系统，通用型的设备管理信息系统无论是自成体系的还是集成在ERP系统内的，基本上都是纯数据的MIS系统，对设备的使用、保养、维修、更换等文档资料的管理功能较弱，更缺乏对设备CAD图纸库的创建与管理功能，尤其是CAD图纸元素与文档资料的链接、CAD图纸参数与数据库的链接等功能基本没有。由于原始设计图纸的缺失、设备改造或更新记录未形成电子文档、未建设备技术参数数据库和CAD图库等原因，导致设备管理人员不能及时掌握设备使用情况，从而不能及时、有效地避免设备故障的发生；设备维修人员不能快速了解设备结构、获取设备图纸和相关技术参数，因此也不能及时选购或加工零部件，不能有效地为设备检修节省时间。

本文利用Object ARX与C#相结合的技术对冷换设备CAD图进行二次开发，采用面向对象的编程方法，解决了CAD图纸元素与文档资料的链接、CAD图纸参数与数据库的链接问题。

1 冷换设备CAD图库总体设计

冷换设备CAD图库开发包括装置平面区域图库、装置工艺流程图库、装置布置图库、冷换设备装配图库。其图纸管理功能有：

1.1 图纸浏览

(1)在首页中通过总貌图热区链接到装置布置图，再从布置图链接到设备装配图。(2)通过设备图库菜单选择要打开的图纸类型和图号，直接打开所选图纸。(3)在图库管理程序中，选择图纸类型打开布置图或流程图，再链接到设备装配图。

上述(1)(3)打开的是DWG格式的CAD图，而(2)打开的是转换成DWF格式的图。

1.2 图纸修改

通过修改数据库中的数据，可自动修改DXF格式的CAD图上的标注尺寸、明细表、开口表。

1.3 图纸添加

先离线画出新增设备装配图，以及在布置图和工艺图上的图标，再复制到指定文件夹，然后添加到图库，并进行CAD图的初始化操作。

1.4 图纸打印

可利用AutoCAD的打印功能实现。

2 系统数据库设计

系统数据库中主要涉及到四张数据表，分别为装置平面区域图表、装置工艺流程图表、装置布置图表、设备装配图表。其数据库的逻辑结构图如图2所示。

2.1 装置平面区域图表包括区域平面图号、区域编码、区域名称、所在装置、所在单位、文件名、文件存储位置、绘制日期、修改记录、备注。

2.2 装置工艺流程图表包括工艺流程图号、单元编码、单元名称、所在单位、所在装置、文件名、文件存储位置、绘制日期、修改记录、备注。

2.3 装置布置图表包括设备编号、设备名称、设备图号、设备类别、文件名、文件存储位置、绘制日期、配件图号、修改记录、备注。

2.4 设备装配图表包括设备编码设备图号、设备名称、工艺编号、工艺名称、箱体长度L3、外头盖长度L2、壳体长度L1、壳体内径D0、壳体壁厚S、设备总长L、支座安装螺栓中心距、壳程出口Ⅰ接管中心定位、壳程出口Ⅱ接管中心定位、壳程进口接管中心定位。

3 Object ARX技术及参数化绘图功能

本系统利用Auto CAD的开放式体系结构，将设备参数数据库和Auto CAD图形库相结合来开发ARX应用程序。ARX应用程序与Auto CAD采用消息传递的方式直接通讯，并由函数AcrxEntryPoint()建立与Auto CAD消息传递的入口，通过Switch语句处理各种消息。在数据的流程设计上，采用自定义绘图类的方式，该方式充分考虑了面向对象的设计方法，完全实现了变量与方法的封装。自定义绘图类，其成员变量为图形的尺寸参数，其成员函数为用于绘制图形的功能函数。类构造代码如下：

4 结论

本系统的开发，完全满足了中石化长岭炼化公司机动处在“冷换设备CAD图绘图要求”文档中提出的用户需求，建立了标准规范的冷换设备图纸库管理系统平台，并提供友好的用户操作界面与便捷的网络访问方式。为进一步开发出具有集数据管理、文档管理、图库管理、CAD二次次开开发发为为一一体体的的通通用用冷换设备管理系统奠定基础。

摘要：本文主要阐述以AutoCAD 2006为开发平台,以Object ARX、C#.NET和MS SQL Server 2005为开发工具建立了冷换设备CAD图库管理系统。用户可以通过输入参数或读取数据库中存储的参数来迅速创建冷换设备的平面图、布置图、装配图等,修改图形的相关参数后又可将数据保存到数据库中,方便数据的循环读取,实现系统的实时交互功能。

关键词：Object ARX,冷换设备,CAD图库,管理系统

参考文献

[1]李长勋.AutoCAD Object ARX2000程序开发技术[M].北京:国际工业出版社,2005.

[2]微软公司.用Visual C#.NET开发Windows应用程序.北京:清华大学出版社,2003.

[3]微软公司.SQL Server2005数据库编程.北京:北京希望电子出版社,2005.

[4]杜立,赵韩,董玉德.基于ObjectARX齿轮设计系统的开发与研究.机械设计与制造,2008,(12):75-77.

[5]王才平,张国军,邵新宇.基于Object ARX的图块重用研究与实现.计算机应用与软件,2006,(12):37-38.

[6]于萧榕,郭昌言,陈刚.结合ObjectARX和C#进行AutoCAD二次开发框架的研究.科学技术与工程,2010.7.

Object 篇2

一直以为遍历Object只能obj.name这种方式，今天做数据比较，才发现

代码如下:

var g2:Object = expensesAC.getItemAt(0);

for(var i:Number=0;i<=23;i++){

if(g2[“times”+i]==“0”){

num--;

}else{

d2g+=g2[“times”+i];

}

}

这种方式，其实觉得Object和java里的HashMap很类似，都是命值对，

具体例子：

代码如下:

private function init:void {

//新建对象

var obj:Object = new Object();

//增加key-value

obj[“name”] = “liguoliang”; //格式: Object[key] = value

obj[“age”] = 25;//注意: key必须为String, value可以为任意类型

//使用for..in...遍历所有的key - value

for(var k:String in obj) {

trace(“Key: ” + k + “ - value: ” + obj[k]);

}

//使用for each..in遍历HashMap

for each( var v:* in obj) {

trace(“value: ” + v);

}

//删除一个key-value

delete obj[“age”];

//使用for..in...遍历所有的key - value

for(var k:String in obj) {

trace(“Key: ” + k + “ - value: ” + obj[k]);

}

Object 篇3

在当今的软件开发过程中,客户需求的改变经常导致已开发或正在开发的程序的大规模的修改,特别是对有关数据库操作部分的修改,这往往不得不对跟数据库操作部分有关的代码重新测试和修改。

出现上述情况的根本原因是由于当今主流数据库是基于表格型的关系型数据库,与基于树型的面向对象技术在结构上有着本质的区别,这导致了应用程序在查询和存储数据时,将应用程序映射到数据库时存在不匹配的问题。

1O/R(Object-Relation) mapping[1]简介

O/R(Object-Relation) mapping,又称对象关系映射,是实现从对象转换为数据库中的数据,并且能够将其从数据库中还原为对象。在面向对象应用中,假如持久化后没有程序对数据库中的数据进行修改,那么持久化后的对象生命周期将超过创建它的应用程序,对象可以被存储在硬盘上,并且在将来可以创建相同状态的对象。而持久化存在复杂关系的对象以后,对其还原仍能保持其原来对象间的关系。

2对象关系不匹配的方面

2.1同一性不匹配

最明显的“阻抗”不匹配就是对象和数据库在同一性方面的不匹配,在Java语言中,Java对象自身与对象包含的值是独立的,所以在Java中对象的比较有以下两种形式(假定存在两个对象A 和B),A==B 或者A. equal(B),因此,在同一性上,对象可以是同一个对象或者对象是相等的,如果它们是相同的那么它们是同一个对象,如果它们是相等的那么它们的值是相等的。Java语言中的这种同一性在数据库中是不存在的,在数据库中只用行包含的值来判断它们之间的同一性。

2.2对象的大小

在面向对象程序设计中,对象的大小比较容易控制,而在将对象映射到数据库后,对象的大小只能用表和列表示。由于在表和列上有固定的限制,这样导致了在将对象映射到数据库时不灵活的数据表示,可以通过增加一种新的数据类型来解决这方面的问题,但是由于当今数据库管理系统对用户自定义类型支持的不完善,采用自定义类型的数据库很难在不同的系统之间移植。

2.3继承

面向对象的特征就是可以继承一个或者多个父类,面向对象通过继承可以很好地模拟问题领域模型,因为SQL数据库不支持继承的概念,而在面向对象语言中使用父类和子类来实现继承,所以在将面向对象模型持久化到数据库中时,在数据库中实现其继承关系是一个很难解决的问题。

2.4关联关系的不匹配

关联关系在对象模型和数据库模型中都存在,在关系模型中关联关系是通过外键关联到被关联对象的主键实现的,而在对象模型中,关联关系主要有三种形式:一对一、一对多、多对多。

2.5域模型与关系模型

域模型是拥有共同功能、结构的一系列应用程序的参考模型,是软件开发的核心模型,使用域模型的应用并不能直接在使用业务实体的表上操作,这些应用有它们自己的面向对象的业务实体模型。域模型在运行时表现为一个关联对象的交互图。业务逻辑不在数据库中执行,而是被实现在应用程序中。这就可以在业务逻辑中使用成熟的面向对象的技术。这对于简单的应用程序,使用JDBC API就可以很容易地处理,然而对于含有复杂业务逻辑的应用,域模型有助于有效地提高代码的可重用性和可维护性。但是在对数据库进行投影或连接时是对结果数据的扁平表示,这完全不同于执行业务逻辑的关联对象,完全不同于关系模型,这是两个完全不同的模型。

对这种不匹配问题的解决需要编写大量的代码。一个主要的原因是在模型化方面,关系模型与对象模型包含相同的业务实体,关系模型有关系理论支持。对象方面没有严格的数学定义和理论工作的支撑。在域模型上的不匹配将直接影响开发效率。另一个原因是JDBC API本身。JDBC和SQL提供了一个面向语句(即命令)的方法,从SQL数据库中来回移动数据。在三个时刻必须指定一个结构化关系,这增加了设计和实现所需要的时间。

3现存的对象关系映射方案

3.1使用JDBC处理持续层

使用JDBC直接持久化是当前比较普遍的持久化方案,它不能够直接在数据库中存储对象,需要将对象转换为SQL语句才能存在于数据库中,当从数据库中取出行时,要将其转换为对象,可以采用现在广为应用的DAO设计模式来隐藏复杂的不可移值的代码。其缺点就是需要为域模型中的每个类编写持久化代码、维护和改动代码所需的工作量大。

3.2使用序列化

在java中,提供了一种将对象转化为字节流的机制,将数据分解成字节流,然后再持久化到数据库中,从而实现持久化。java对象序列化不仅保存一个对象的数据,而且递归保存对象引用的每个对象的数据,可以将整个对象层次写入字节流中,序列化一个对象可能得到整个对象序列,这样在反序列化对象时需要反序列化有关系的多个对象,才能取出所需要的对象,这将大大降低数据库的性能。

3.3EJB中的实体Bean

EJB规范定义了CMP的两种持久化方式,Bean自身管理的持久化方式(BMP)和容器管理的持久化方式(CMP)。

(1) BMP需要在代码中维护持久化开发,需要开发者自己编写数据库访问的代码,直接对数据库进行持久化操作,给开发者更多的开发空间,灵活方便。

(2) CMP不需要开发者自己编写数据库访问的代码,其持久化由EJB容器来管理实现,减少了开发者的工作量。但是CMP Bean 与数据库中的表是一一对应的,CMP是通过代码生成来实现持久性代码,因此很难在CMP中实现动态查询,并且通过Web层调用的时候需要通过远程接口来访问EJB中的对象,容易降低系统的性能,对于开发者来说,出现了错误非常不容易调试。

3.4面向对象数据库

直接将面向对象模型存储在数据库中,模型关系保持不变,由于当今广泛采用的都是关系数据库,并且面向对象数据库的技术不是很成熟,所以面向对象数据库的流行在短期内不容易实现。

3.5使用XML持久化

对序列化模式的扩展,通过它可以解决序列化后字节流的限制,它只是一种文本格式,使用XML来持久化对象容易导致对象层次间的不匹配。

3.6对象关系映射解决方案

对象关系映射是解决对象和关系数据库之间的不匹配,通过对象关系映射,能够直接将对象持久化到数据库中,而不需要对象关系转换到关系模式。这种映射应该独立于程序本身,并且完全支持面向对象的特点,通过使用对象关系映射不需要随着需求的变化对持久化部分进行大规模修改,这样就大大提高了程序开发的效率,这类解决方案比较适合于存在主键并且表之间的连接是通过外键连接的数据库模式,通过使用对象关系映射不需要开发者对SQL有很好的理解就可以实现这种映射,让开发者更关注业务层。这一类的产品主要有Hibernate[2]、JDO。Hibernate是通过Java中的反射机制和运行时字节码生成来实现的,而JDO主要是通过字节码修饰来实现的。

对象关系映射克服了其他持久化方案的缺点,并且提供了许多附加的功能。对象关系映射方案简单易用,对面向对象提供了完全性支持,采用优化方案提高了其性能,对象关系映射主要有以下特点:

(1) 不像其他的持久化方案,对象关系映射可以通过键值属性文件或XML来对映射进行灵活地配置。它可以独立于程序存在,不需要实现特定的接口,扩展性强;它的运行不需要特定的容器,可以运行在容器中,也可以运行在普通的程序中。

(2) 对面向对象提供完全支持,支持面向对象的全部特点,而不是部分特点,例如:继承、自定义类型等各种面向对象特点,这样开发者就可以在开发中充分发挥面向对象的特点,而不必担心持久化方案对面向对象支持的不充分修改程序才能实现对象持久化。

(3)不影响程序的性能,通常的看法就是认为持久化方案有可能影响程序的性能,影响程序性能的关键在于执行最少的数据库查询,持久化方案应该保存对数据库插入和更新的数据,当程序中对象的状态没有改变时并不对对象进行更新,这样就大大减少了查询的次数,持久化方案通常还提供如下几种性能优化机制,例如使用延迟加载,延迟对对象的读取,当程序中的对象存在关联关系时,并不对关联对象进行加载,只有当程序真正读取对象时,才真正加载对象,另外还采用对象缓存等机制来提高性能。

尽管对象关系映射解决方案很强大,它也存在不足,特别是对于一些通过列之间的关系进行关联的数据库进行修改时,对象关系映射不是最佳方案,对于这类系统使用对象关系映射将花费更多的精力。

4对象关系映射关键技术

4.1实现类的继承

在面向对象中,类中间的关系是 is a 与has a 的关系,而在数据库中主要的关系是has a 的关系,在数据库中实现继承主要有以下三种方式:

(1) 每个具体的类一个表

所有抽象类的属性都映射到具体的表中,如图1。

在这种映射模型中,由于是将每个具体的表映射到数据库中的表,而在数据库中是通过外键来确定表和表之间的关系,因此通过这种映射方式将不能使用多态和继承。

(2) 每个继承关系一个表

整个类关系映射在表中,这样这个表将包含位于继承关系中类的所有属性。通过这种方式来实现类到关系的映射比较简单并且在性能方面具有优势,可以很容易实现,这种方式面临的问题就是在子表中的属性映射到表时其属性列必须可空,这样在数据库中设置“不空”条件时就面临着冲突,这种方式很容易实现。

(3) 每个子类一个表

类中的继承关系映射到表中的外键,每个子类以及其父类都映射到数据库中的表中,这样就完整地将整个类的关系映射到数据库的表中,表和表之间通过外键来设置它们之间的关系,如图2所示。这种映射模式适合用于类和类之间有着复杂的继承关系,不适合用于类和类之间不存在继承关系的情形。

4.2聚合关系的实现

(1) 单表聚合方式

对于对象之间的关系可以有两种方式来实现聚合映射,如果聚合对象类型之间的关系是简单的1:1关系,可以用这种方式来将被聚合对象的属性和使用聚合对象的属性放到同一张表中,因此这种方案的性能是比较好的。通过读取一张表就能将聚合对象和被聚合对象读入,同时由于一次读入所有聚合对象,因此有可能读入很多无用字段,浪费大量的IO带宽。

(2) 外键聚合

如果聚合对象之间的关系是1:n, 那么可通过外键聚合方式,将聚合对象和被聚合对象分别映射到各自的表中,在聚合对象中通过外键引用被聚合对象,通过这种方式来实现需要多次访问数据库,这种方式适合于被聚合对象的访问几率比较小的情况。占用的空间小,在数据库同一性方面,由于被聚合对象不会因为聚合对象的删除而删除,需要通过编程或使用数据库中的触发器来实现。

4.3对象间关联关系的实现

(1) 如果对象间的关系是1:

n(包括1:1),这种方式是通过外键方式来实现,在依赖对象的表中插入所属对象的ID。

(2) 如果对象间的关系是多对多的关系,它是1:

n的拓展,需要单独建立一个表,来存放对象间的关系,例如员工和部门之间是多对多的关系,增加一个表,如图3所示,表conversion中字段refEmployee和refDepartment分别是对ProxyIDA和ProxyIDB的引用:

5总结

本文在深入分析对象关系映射不匹配出现的背景并对当前各种解决对象关系映射的方案进行了对比分析,深入研究了其技术特点,最后对实现对象到关系映射的三个关键技术进行了研究和分析,从而为企业选择合适的对象关系映射做了理论准备。

参考文献

[1]Scott W.Ambler,The Design of a Robust Persistence Layer for Rela-tional Databases[EB/OL].http://www.Ambysoft.com,2000-11-28/2001-11-20.

[2]Project:Hibernate[EB/OL].http://sourceforge.net/projects/hiber-nate/,2003-03-01.

[3]夏晰.深入浅出Hibernate[M].北京:电子工业出版社,2005.