数据访问模式（共8篇）
数据访问模式 篇1
传统的Web信息系统中,每次对数据的读取、修改和写入需要与数据库交互。这种方式存在以下弊端:(1)每次数据的访问需要建立数据库连接,读取记录,销毁连接等操作,而这些操作需要消耗服务器资源、影响服务器性能。(2)随着网络上用户访问量增加,数据库访问的并发数在增大,服务器负担相应加重;当并发数增大到一定程度时,服务器可能不堪重负而出现宕机问题。因此,减少服务器数据库的访问量,提高系统的性能是十分必要的。
国内学者对连接池研究比较多,所涉及的文献也比较多。连接池主要是建立与数据库连接的对象池,从连接池中取出连接对象构建与数据库的连接,从而避免大量重复新建、撤销连接对象的系统开销,提高服务器的性能和响应[1,2,3]。笔者借鉴了这种思想,提出了一种基于资源池的数据访问模式,即把数据库中的每一个记录视为一个资源对象,用资源类来描述。把资源对象放入资源池保存,需要时从资源池中取出使用即可。笔者对基于资源池的数据访问模式进行了有益的探索,很好地解决了传统模式中大并发量数据访问需要频繁访问数据库数据这个弊端。
1 基于资源池模式的软件设计
1.1 资源池的工作原理[4]
资源池工作的基本思想如图1所示,所谓资源池就是数据库信息的“缓冲池”。 影响服务器性能的关键因素是建立数据库的连接、信息的读取、连接的关闭、信息显示这些操作。如果把数据库记录的信息事先放入“缓冲池”,当用户访问记录信息时,从“缓冲池”中取出对应的记录信息返回给用户即可,由于“缓冲池”位于服务器内存中,可以快速访问,且免去频繁与数据库连接的操作,因此就提高了服务器的响应时间,提高了服务器性能。
1.2 资源池模式的软件设计[5]
在资源池模式的软件设计中,存在Resource,ResourcePool和Client三个角色,其关系如图2所示。
1.2.1 Resource
可重用资源对象。在Web信息管理系统中,数据库中的每一条记录视为一个Resource对象,数据库表的字段对应Resource类的属性。
1.2.2 ResourcePool
资源池对象。ResourcePool是资源Resource的集合,负责管理资源对象。通常情况下,为了使用相同的策略管理Resource对象,应将数据库同一个表中的记录对应的Resource对象放在同一个资源池中。资源对象池采用SingleTon的设计模式,使得整个应用程序使用同一资源池。
1.2.3 Client
客户对象。Client对象是指使用资源池对象和资源对象的客户端应用程序,Client对象通过资源池对象管理资源对象,获取资源对象,使用资源对象。
资源池模式的核心在于:被资源池管理的对象一定是可重用的对象或组件。在Web信息系统中,数据库所在的记录需要重复读写,是可以被重用的资源对象,因此可以利用资源池模式来对这类资源对象进行管理。
2 资源及资源池的实现
本文以图书管理信息系统为例来说明信息系统中资源及资源池的实现,根据图书信息管理的工作实际,确定图书管理信息系统由四大模块组成,即:图书信息模块、图书借阅管理模块、用户信息管理模块和系统管理模块。系统数据库包括书目信息表、图书信息表、借阅信息表、用户表等[6]。
2.1 可重用资源(Resource)
在系统数据库的书目信息表、图书信息表、借阅信息表中,每一个信息记录对应一个资源对象,可由一个Resource类来实现。图3所示为图书管理信息系统中资源与资源池的类图[7]。
图3中,BibliothecResource类图表示了书目资源类的UML类图,其属性字段与系统数据库中的书目信息表字段相对应,分别为书目编号、图书名称、作者、出版日期、ISBN、价格、图书类型、现成数量、馆藏地点、简介、待入库数量[8]。Create()是构造方法,用来初始化生成资源类的字段。借阅者资源类(BorrowerResource)、图书资源类(BookResource)与书目资源类相似,包含属性字段和构造方法。利用面向对象语言的继承与多态,使这些类都实现一个相同的IResource接口。
2.2 资源池(ResourcePool)
资源池利用单件模式设计,单件模式保证一个类在软件系统的整个生命周期中仅有一个实例,并提供一个访问它的全局访问点[9,10]。单件模式是为了解决在多线程环境下,有可能引发资源访问冲突问题而提出的。单件模式的最大特点是该类的构造方法被声明为private访问权限,这样只能在该类内部调用构造方法和防止该类被继承而创建多个实例,同时声明一个名为getInstance()的静态同步方法来获取这个类的唯一实例。
资源池ResourcePool使用一个静态聚合对象,该对象具有Add,Remove,Clear等方法,用于向集合中添加,移除和清除所有对象元素。C#集合框架中有很多类都能充当这个资源池,如Arrarylist,Hashtable,List等。这里采用Hashtable集合来保存Resource对象,因为它基于链表这种数据结构,具有快速插入和删除的优点,符合取出和保存Resource对象的要求。以后访问需要的资源时直接从集合中取出Resource对象 ,这样只相当于在内存中进行操作,可以避免访问数据库造成的开销。如图3所示,在图书管理信息系统中,根据数据库中的信息表,建立书目资源池BiblicathecaPool,借阅者资源池BorrowerPool,图书资源池BookPool等多个资源池,利用面向对象语言的继承性,这些资源池都继承父类ResourcePool,共同使用ResourcePool中的方法,同时在子类中实现自己特殊的方法。在资源池ResourcePool中有几个典型的用例(use case)
2.2.1 初始化
Init()方法,一般是池管理器(PoolManager)在执行引导(bootstrap)时调用。该方法一方面实例化Checker,启动守护线程定时扫描资源池,将其中不符合策略要求的资源从资源池中删除。另一方面按照单件(Sington)模式,实例化资源池类,并按一定策略(如热门书目,访问量最大的书目)填充一定数量的资源到资源池。
2.2.2 查找资源
静态FindResource()方法,此方法根据资源的Key在资源池中查找对应的资源。若找到资源,返回该资源;若在资源池中找不到资源,就建立数据库连接,编写SQL查询语句从数据库中查找资源并将该资源加入到资源池,并返回资源;若数据库中也没有对应的资料,返回空值。FindResource()方法主要是读取资源,为了防止多个线程在读取资源的过程中,另外地修改线程将资源值进行修改,必须使用ReaderLock来锁定FindResource()中的程序。
2.2.3 移除资源
静态RemoveResource()方法,它是将资源从资源池中移除,同时将数据库中对应的记录删除。为防止移除资源时,其它线程读取、操作资源,使用WriterLock来锁定该方法。该方法主要用在客户端后台管理功能模块中,当删除数据库记录时,调用此方法。
2.2.4 添加资源
静态AddResource()方法,当管理员向数据库中添加记录时调用此方法。此方法调用数据库操作方法向数据库中添加记录,同时将该资源加入到资源池中供用户访问。
每个资源池都有一个守护线程Checker,Checker中有一个定时器对象Timer,定时对资源池进行扫描,将不符合资源池管理策略的资源从资源池中删除,维护资源池的正常运转。
2.3 资源池管理策略[11,12]
资源池的实现通常需要一系列强制执行的策略来决定运行时行为包括资源分配策略,资源数量控制策略,定时策略,线程同步策略。一个连接池的自我管理,实际上就是通过定时地对其每个资源的状态、资源的数目进行判断而完成相应操作。
2.3.1 分配策略
当客户请求信息资源时,首先看资源池中是否有用户需要的信息资源。如果存在需要的资源则把该资源分配给客户,若连接池中没有用户需要的信息资源,则由资源池FindResource()方法负责在数据库中查找需要的资源,并加载到资源池,来满足客户请求。
2.3.2 资源数量控制策略
资源池创建的时候,所包含的已初始化的资源对象的最小数目被称为低水位线,最大数目被称为高水位线。资源池初始化时,需要添加一些访问量大的热门资源以及一些最新资源,因为这些资源经常被访问。如果资源池在使用期间,来了新的资源对象请求,将会触发创建新的资源对象的动作,由FindResource()方法创建新的资源对象并添加到资源池中;如果资源池中的对象数目超过高水位线,由维护线程将访问量小的资源或者超时的资源删除。
2.3.3 定时检测
通过在配置文件中设置资源池的参数来控制资源池中每个资源的最大空闲时间,在资源池初始化时,读取配置文件来设置资源的最大空闲时间。为了保证资源池中每个资源都处于有效的工作状态,如果某个资源超出最大空闲时间时,就认为此资源是无效的,则将它从资源池中删除。
2.3.4 线程同步策略
当图书管理信息系统访问量比较大时,多个线程之间的同步问题是比较重要的。在一个线程修改资源池时,所有访问线程此时应处于锁定状态以防止出错,譬如一个线程刚删除了一个资源,另外一个线程正好要访问该资源,此时应用程序会出现问题。这里我们使用读写锁ReaderWriteerLock来实现线程的同步[13],在任一特定时刻,它允许多个线程同时进行读取资源,或者允许单个线程进行写访问。
3 测试结果及分析
3.1 测试环境
硬件环境: 处理器AMD Sempron X2 190,内存 1024 MB。软件环境操作系统:Windows xp。开发平台:vs.net 2008。
运行环境:IIs+SQL2005。实用工具:msnetstat。
资源池管理策略的设置:置低水平线为100个(书目资源)和高水平线3 000个(书目资源),最大空闲时间3 min。
3.2 测试结果及分析
表1是传统模式下从数据库中读取图书信息时间消耗的试验结果,其中,n表示创建并返回给用户的图书书目资源数(单位:个);t表示花费的时间 (单位:毫秒)。创建一个书目资源对象需要的平均时间大约为T= (153.2-26.2) / (500-1) =0.254 ms 。表2是资源池模式下从资源池中取出图书信息对象,然后将该对象放回到资源池的时间消耗测试结果,创建一个书目资源并放回资源平均花费的时间大约为T=(3.97-3.02)/(500-1)= 0.001 9 ms。
比较表1、表2发现:在传统模式下,资源数从100个增加到500个,消耗时间从41.7 ms增加到153.2 ms;而在资源池模式下,资源数从100个增加到500个,时间仅从3.54 ms增加到3.97 ms,显然随着资源数的增加,资源池模式的时间消耗明显减少。而且当资源数从1个增加到500个时,传统模式与资源池模式消耗时间相隔0.254/0.001 9=113.7倍,可见基于资源池模式的数据访问方式,服务器响应性有显著地提高。
4 结束语
由测试结果可以看出,如果在同一时间访问数据库的连接请求超过 10 个,资源读取的时间消耗就会大幅增加,就需要引入资源池。目前,随着Web信息系统的应用越来越广泛,系统要给用户提供并发的快捷、稳定、高效的服务,就离不开一个健壮的信息访问模式的支持。本文提出的基于资源池模式的数据信息访问方式,应用在图书管理信息系统的开发中,证明能明显地提高信息系统的性能,提高服务器端的资源利用率。
试对数据库访问技术进行研究 篇2
关键词：数据库访问技术；ADO.NET；安全性
中图分类号：TP311.13 文献标识码：A文章编号：1007-9599 (2011) 15-0000-01
Database Access Technology Research
Li Bin
(Guangdong Gaoyao People's Hospital,Zhaoqing526040,China)
Abstract:At present,along with the WWW growing,database access technology has gradually become the focus of the IT technical staff,understand and master the technology of database access,help to better the technology application.This article first elaborated the database access technology development,and based on the ADO.NET data access techniques are studied, for reference only.
Keywords:Database access technology;ADO.NET;Safety
一、数据库访问技术的发展
Web进入编程时代以前，在大部分IT人员眼里，数据访问仅仅是一个相对而言的问题，即需要使用到的所有数据都是自己事先准备好的。大多人关心的问题是如何选择性能好、价格低的数据库服务器，并且系统中涉及的全部模块必须和服务器兼容，其中客户机和服务器的应用是这种两层模型较为典型的范例。
在很短的时间内，三层系统模型发展成了Windows DNA，即Microsoft.NET服务器系统。该系统主要是利用统一的模型进行数据访问，其注重的是内容，而不是存储媒介及数据格式，具体的表达方式完全是建立在UDA的基础上的。为了提供一种通过VB方便访问OLE DB功能的途径，Microsoft设计了ADO。
ADO提供了对脱机记录集、服务器端游标和XML的支持，不仅增强了访问功能，同时还提高了访问效率。为了便于在Web环境下进行数据传输，Microsoft对ADO进行了优化。但是随着人们对可伸缩性以及协同工作能力要求的不断提高，ADO已经渐渐无法满足这一要求，ADO.NET随之出现。
二、ADO.NET数据访问技术
.NET框架是由微软公司推出的一个应用平台，在该平台中ADO.NET是Windows Forms和ASP.NET应用访问数据的标准服务，通过ADO.NET能够访问由.NET提供的不同类型的数据源。ADO.NET可以有效地从数据操作中把数据访问分解成若干个單独使用的组件。ADO.NET可以直接处理检索到的结果，或是将结果放入DataSet对象，并以特殊的方式向用户公开。
（一）ADO.NET的特点。ADO.NET是采用高度分布、松散的应用程序进行设计的，这类程序通常使用HTTP在逻辑程序连接中通信，XML便成为在该连接中交流数据的最佳选择，这是因为文本XML格式较为适合HTTP，当全部连接都处于同一网络时，XML通信提供了最大的灵活性。ADO.NET数据访问具有以下特点：1.不依赖于连续的活动连接。由于被打开的数据库连接会占用一定的系统资源，在正常情况下，数据库仅能维持少量的并发连接，并且维持这些连接会使应用程序的总体性能有所降低。而使用ADO.NET进行数据访问则是以较有节制使用连接的结构作为中心设计出来的，从而使应用程序连接到数据库的时间足以更新和获取数据。在这样的情况下，数据库未被大部分的时间空闲连接所占用，因此，能够为大量的用户提供服务。2.数据能够被缓存到数据集中。较为常见的数据任务是从数据库检索数据随后在对数据进行某些操作，例如显示及处理数据，或是将数据发给别的组件。但很多情况下，应用程序若是在每处理一条记录就返回一次数据库，显然是不切实际的，所以最佳的解决方法就是将从数据库中检索到的记录进行临时存储，然后再对该临时集进行使用，这就是数据集的概念。数据集其实是数据源检索到得记录的缓存，其工作方式好比虚拟的数据存储区。数据集里面的数据一般是数据库中内容的精简版本，可以采用和操作数据类似的方式对数据集进行操作，操作时数据集能够保持与数据库的不连接状态，从而使数据库可以自由执行其他任务。使用数据集最便利的地方在于组件能够按照需要交换数据集。因此，组件不必分别查询数据库。3.数据集独立于数据源。虽然数据集是从数据库中获取数据的缓存，但是两者之间却并没有任何实际啥关系。可以将数据集看作是一个容器，填充这个容器的主要内容是从数据适配器执行的SQL命令或存储过程。由于数据集并没有直接绑定在数据源上。因此，数据集则是来自于多个源的数据的集成点。
（二）ADO.NET数据访问技术的安全性研究。1.安全的ADO.NET连接。为了确保应用程序的安全，首要目标就是保护对数据源的访问，而要想保护对数据源的访问，就必须保持用户的密码、标识以及数据源名称等连接信息的私密性。应避免用纯文本的形式存储用户的密码和标识。因为这样做会造成严重的安全漏洞。用户的密码和标识属于源代码的一部分，如果源代码的安全受到威胁，那么用户的密码和标识则很容易遭受攻击，即便向外部源提供的代码是编译后的版本，也很有可能会被反汇编，从而导致用户的密码和标识被公开，所以说用户的密码和标识绝对不能用纯文本的形式存在于代码中。因此，在连接到Microsoft SQL Server时，可以使用集成安全性，这是因为集成安全性使用的是当前活动活动的标识，而不是传递用户的密码和标识。2.安全的ADO.NET编码。确保应用程序的安全还包括编写安全的代码，而代码则必须只公开客户端代码所需的信息和功能。通常在ADO.NET中最常见的攻击是SQL Insertion攻击，攻击者主要是通过在数据源位置插入其他的SQL语句来达到攻击的目的，这些命令不但能够破坏会修改数据源位置的信息，而且还可以检索用户的私人信息。为了防止SQL Insertion攻击，必须对来自外部源的输入进行验证，并传递列值作为参数，而不是串联这些值来创建SQL语句。
三、结论
总而言之，ADO.NET数据库访问技术具有不依赖于连续的活动连接、数据能够被缓存到数据集中和数据集独立于数据源等优点，必将得到广泛的应用。但在具体使用中必须对其安全性加以注意。只有在确保其安全的基础上，才能更好地发挥该技术的各种优点。
参考文献：
[1]吉占占.基于DataSet和ADO.NET的文献检索列表转换软件设计[J].计算机应用与软件,2009,6
[2]王丽芳.基于ADO.NET的O/R Mapping中间件的研究[N].西北工业大学学报,2010,6
数据访问模式 篇3
软件复用 (Software Reuse) 是将已有软件的各种相关知识用于建立新的软件, 缩减软件开发和维护的花费, 以提高软件生产力和质量的一种重要技术。本文从“设计复用”的角度出发, 探讨对多种类型的数据库访问提供支持的数据访问层组件构建技术, 该技术以GOF工厂模式为核心, 为逻辑访问层调用提供统一接口。该组件开发完成后, 项目组可根据项目所采用的数据库管理系统类型, 对组件的配置文件中相关XML节点进行修改, 无需重新编译, 即可实现对该组件的顺利集成。同时, 对一些数据库管理系统类型不确定的项目, 要顺利实现数据访问的迁移, 也仅需修改XML节点中相关文本而已。
下面, 本文以ASP.NET应用项目数据访问层设计为例, 介绍简单工厂模式实现方案和抽象工厂模式结合反射技术实现方案。
1 相关理论
1.1 工厂模式
设计模式是从具体问题抽象来的, 这种具体问题在特定的上下文中重复出现, 它捕获了在一定语境中包含相关作用力的问题的解决方案的本质结构和内在含义, 并且这种解决方案被证明是成功的。工厂模式通过一个专门负责实例化的类来获得具体的对象, 通常我们将这个类称为“工厂”。工厂类封装了相关对象的构造逻辑, 分离了子类对象构造与定义, 使得软件产品的可维护性大大增强。
1.2 反射技术
反射 (Refection) 是.NET中的重要机制, 通过反射, 可以在运行时获得.NET中每一个类型的成员, 包括方法、属性、事件以及构造函数等, 还可以获得每个成员的名称、限定符和参数等。有了反射, 即可对每一个类型了如指掌。
2 实现方案
2.1 简单工厂模式实现方案
需实例化的类具有相同的接口, 种类有限并且基本不需要扩展时, 可以使用简单工厂。采用简单工厂的优点是可以使用户根据参数获得对应的类实例, 对ASP.NET而言, 这样的参数可以预先存储于Web.config配置节中, 参数发生变化, 无需修改类本身, 提高了可维护性, 并且通过工厂避免了直接实例化类, 降低了耦合性;缺点是可实例化的类型在编译期间已经被确定, 如果增加新类型, 则需要修改工厂。
因此, 若采用简单工厂模式实现数据访问层的可适应性, 类图如图1所示。
DataVST类作为提供数据访问层接口功能的抽象类, 提供了查询和执行SQL及存储过程的方法定义, 而具体的实现, 由3个子类:OracleDataVST、SQLDataVST、OleDBDataVST提供。同时, 为了保证数据访问层对象只有一个全局唯一的实例, 防止程序在内存中重复构建数据库连接与数据库访问对象, 在子类中采用了单件模式, 将构造函数设置为私有, 保存惟一实例的静态私有变量, 并提供了初始化并获得惟一实例的静态方法GetInstance, 工厂类CreateDataVST在构造数据访问对象时, 只能通过GetInstance方法获取对子类对象的引用。工厂类的Create方法通过读取ASP.NETWeb.config配置文件的appSettings节, 获取数据库类型字符串, 创建相应的数据访问对象, 并通过父类DataVST引用返回。这样一来, 外部对象可通过CreateDataVST.Create () 方法调用获取到数据访问对象, 由于数据访问对象是通过父类引用变量引用, 并未涉及到具体子类对象, 因此, 如果数据库发生改变, 只需要修改web.config配置文件即可。
简单工厂实现的数据访问层, 大大提高了数据访问层的可维护性。但是, 从类图中可以看出, Connection、Command和DataAdapter除了具体的类型不同外, 子类中每个函数的操作完全相同, 代码有大量的冗余, 如果修改一个操作, 则必须修改所有子类中的相应操作。这种结构的另一个缺陷就是采用简单工厂不易扩展, 增加数据库类型后, 工厂方法就需要修改, 而这不符合“开-闭”原则:软件实体应当对扩展开放, 对修改关闭。
通过进一步分析可知, .NET针对Connection、Command、DataAdapter和Parameter提供了相同的接口, 即IDbConnection、IDbCommand、IDataAdapter和IDataParameter。如果能用某种方法获得对应的实例, 即可简化数据库访问对象, 为此下节提出第二个解决方案。
2.2 抽象工厂模式结合反射技术实现方案
简单工厂模式实现方案中提到了两个问题: (1) 简单工厂中提供具体数据访问方法的子类, 每个方法的实现完全相同, 只是所使用的系统类不同, 代码有大量冗余; (2) 不易扩展, 增加数据库类型后, 需要修改工厂方法。
采用抽象工厂模式, 将Connection、Command、DataAdapter和Parameter对象的构造, 交给具体的数据访问子类完成, 从图1可以看出, 数据访问子类提供了4个方法, 分别用于返回各自的Connection、Command、DataAdapter和Parameter对象, 而DBOperator对象实现数据库的查询与执行操作, 这些操作通过引用DataVST对象, 获取具体的数据库操作系统对象, 从而将数据库的查询和执行操作封装到了DBOperator类中, 消除了代码冗余。
同时, 数据访问层中新增的CreateDataFactroy类, 提供了Create方法, 该方法可以这样设计:
从web.config文件AppSetting配置节读取数据访问子类名, 包括OracleDataVST、SqlDataVST、OleDBDataVST, 利用.NET反射技术, 获取到这些类型名称的构造器, 并调用构造器构造对象, 解决了简单工厂模式不易扩展的问题, 并将对CreateDataFactroy.Create () 方法的调用封装到DBOperator类的构造函数中, 反射技术的使用对业务逻辑层完全透明, 业务逻辑层请求数据访问服务仅需构造DBOperator不带参数的构造函数, 从类的易用性角度考虑也是非常优秀的。
3 结束语
本文以多数软件系统设计均需涉及的数据访问层组件设计为例, 介绍了具有良好的可复用度、较强的需求变更应对能力的设计方案, 该方案以抽象工厂模式和反射技术作为支撑, 所生成的数据访问层, 封装了支持目前主流数据库管理系统的访问技术, 能被广泛地使用于各种类型的信息系统开发中。
摘要：数据访问层封装了软件系统中与数据库访问直接相关的逻辑代码, 对于开发团队而言, 如何有效地复用数据访问层组件, 并使得软件系统能在各种数据库间方便地迁移, 对于提高模块复用度, 提高团队开发效率有着非常重要的意义。从设计模式的角度, 探讨了数据访问层的两种设计方案, 并重点分析了抽象工厂模式与反射技术相结合的解决方案, 该方案经过多次开发实践的检验, 具有可复用性强、复用方法简单的特点。
关键词：工厂模式,数据访问,设计模式,反射技术,软件复用
参考文献
[1]甄镭..NET与设计模式[M].北京:电子工业出版社, 2005.
[2]李礁.多态性结合反射工厂模式以提高.NET应用程序可维护性的研究[J].数字技术与应用, 2009 (1) .
数据访问模式 篇4
所谓模式,简单的讲就是一个较好的研究的摸板。而设计模式就是设计摸板。多年前,一个名叫克里斯托佛·亚历山大的建筑师对建筑,街道等人类所建造的各种生活空间进行了大量的观察发现后,优秀的结构都有一些共同之处。在寻找和描述设计质量的探求中,亚历山大认识到,必须观察为了解决同样的问题而设计不同结构。通过观察解决相似问题的不同结构可找出设计之间的相似之处。他将这种相似之处称为模式。亚历山大对模式的定义是“在某一环境下对某个问题的一种解决方案”。模式是一条由三部分组成的规则,它表示了一个工作环境、一个问题和一个解决方案之间的关系。每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动。
模式的描述包括以下内容:
1)模式的名称;
2)模式的目的;
3)实现方法;
4)限制和约束因素;
亚历山大在1970年代编制了一本汇集设计模式的书。但是这种设计模式的思想在建筑设计领域里的影响远没有后来在软件开发领域里使用的广泛。
1 软件设计模式概述
软件开发中存在大量相同的方式解决重复出现的问题,是否可以用模式的方式来设计软
件呢?于是就出现了软件设计模式(面向对象的软件设计)。将设计模式引入软件设计和开发过程的目的在于充分利用已有的软件开发经验,这是因为设计模式通常是对于某一类软件设计问题的可重用的解决方案。优秀的软件设计师都非常清楚,不是所有的问题都需要从头开始解决,他们更愿意重复用以前曾经使用过的解决方案,每当他们找到一个好的解决方案,他们会一遍又一遍地使用,这些经验是他们成为专家的部分原因。设计模式的最终目标就是帮助人们使用优秀的软件设计师的集体经验,来设计出更加优秀的软件。
“四人帮”(GOF)模式被认为是所有其他模式的基础,23种设计模式分为3类:创建型模式(Creational Pattern),结构型模式(Structural Pattern)和行为型模式(Behavioral Pattern)。抽象工厂设计模式是这23种设计模式中的一种。
2 抽象工厂设计模式概述
2.1 简单工厂模式
简单工厂模式不能说是一个设计模式,但它在实际的编程中经常被用到,而且思想也非常简单,说它是一种编程习惯可能更恰当些。它的作用是实例化对象,被创建的实例通常都具有共同的父类或接口,它的优点是用户可以根据参数获得对应类的对象,通过它,外界可以从直接创建具体产品对象的尴尬中摆脱出来。简单工厂的结构如图1所示。
从图1的结构上可以看出,客户只需知道父类和工厂,工厂是整个模式的核心,简单工厂模式能够适应一定的变化,但是它所能解决的问题是远远有限的。它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂了。
2.2 抽象工厂设计模式
抽象工厂设计模式向客户端提供一个接口,使得客户端在不必指定具体类型的情况下,创建多个产品族中的对象。抽象工厂设计模式可以实现一次创建一系列相互依赖对象的需求,其结构如图2所示。
从图2所示,整个模式中有以下几类:
抽象工厂:主要功能是生产抽象产品。
抽象产品:主要功能是提供实体产品访问接口。
实体工厂:主要功能是生产实体产品。
实体产品:主要功能是实现功能。
3 抽象工厂设计模式在数据访问中的应用
在我们使用三层结构开发应用系统中,在数据访问层使用抽象工厂设计模式,可将图2.2进行改造,得到如图3所示。
如图3所示:实体工厂包含有SQL Server和Access两种。它们分别生产实体产品访问对象;抽象产品提供实体产品数据访问接口;实体产品根据实体工厂的数据访问类型SQL Server和Access,分别实现不同的数据访问。
以OA办公管理系统为例创建三层及数据访问,1)创建数据访问层的基本架构,创建抽象工厂OADataFactory,创建抽象产品OAData;2)实现数据访问接口;3)完成对象创建;4)完成三层调用。OA办公管理系统三层依赖关系如图4所示。
如图4,在OADAL数据访问层中根据访问数据库的不同,分别实现Sql Server、Access或者其它数据库的访问功能。在抽象工厂OADataFactory项目中分别创建抽象工厂类AbstractDataFactory、SqlServer实体工厂类SqlDataFactory和Access实体工厂类AccessDataFactory。其中AbstractDataFactory用于提供数据访问对象的创建,其相关代码为:
SqlDataFactory用于实现Sql Server数据库访问对象的创建,AccessDataFactory用于实现Access数据库访问对象的创建。
在业务逻辑层调用数据访问层时,通过抽象工厂调用实体工厂,实体工厂中的实体产品给抽象产品,抽象产品调用数据访问方法。
4 结束语
使用抽象工厂设计模式实现数据访问功能,可以提高系统使用数据库的选择,同时也可以降低业务逻辑层和数据访问层之间的耦合。系统无论使用Sql Server数据库或者Access数据库都不受任何影响
摘要：设计模式分创建型模式,构型模式,和行为型模式。抽象工厂设计模式是其中的一种,它向客户端提供接口,使得客户端在不必指定具体类型的情况下,创建多个对象。抽象工厂设计模式可以实现一次创建一系列相互依赖对象的需求,在实现数据访问功能中用于提供系统使用数据库的选择,同时也可以降低业务逻辑层和数据访问层之间的耦合。
关键词：数据访问,抽象工厂设计模式,抽象工厂,抽象产品
参考文献
[1]杨莉..net应用[M].北京:电子工业出版社,2009.
[2]王翔.设计模式——基于C#的工程化实现及扩展[M].北京:电子工业出版社,2009.
数据访问模式 篇5
关键词：C#数据库访问,移植性
ADO.NET是Microsoft公司在.Net平台下提出的新的数据访问模型。ADO.NET结构图如图1。在ANO.NET2.0中,可以使用多种.NET Framework数据库提供程序来访问数据源。数据提供程序有:1)SQL Server.NET Framework;2)Oracle.NET Framework;3)OLE DB.NET Framework;4)ODBC.NET Framework。该文针对SQL Server.NET Framework的访问模式做进一步的探讨。
1 模式描述
按照ADO.NET提供的访问模式,常用的做法是第一步建立Connection对象,建立Connection对象常用的方式是将本地计算机名,用户名,密码等以字符串的方式进行描述;第二步创建Command对象的字符串,例如查询方式,查询内容等。第三步则是打开连接,执行命令即可。这种做法能解决实际问题,但是系统的移植性很差,修改起来不方便。因此为了解决这种问题,设计了一种方便移植性数据库访问方式。
1.1 配置app.config文件
针对Connection对象所建立的数据库的连接语句,采用配置文件来处理。设置数据库的连接属性。方法如下:
在程序设计中,利用ADO.NET提供的configuration类来读取。采用System.Configuration.ConfigurationSettings.AppSettings["字符串名"]获得相关数据库的参数。从而提高系统的可读可修改性。
1.2 设计通用访问接口
从代码的独立性考虑,对于数据库的访问,采用单独的类来进行描述,有利用提高代码的重用性和可维护性。由于ADO.NET对于SQL的查询语句采用SqlCommand类进行描述,同时提供了三种执行方式,针对这三种执行方式,设计相关的通用类。方法如下:
1.2.1 不带返回结果集的SQL语句,设计转换接口
1.2.2 返回SQL语句第1行第1列的语句,设计转换接口
1.2.3 返回SQL语句的结果集
以上方式是在调用原有的数据库访问API上进行封装,然后利用ADO.NET提供的数据库访问方式连接数据库,再调用相应的API。若以后需要进一步的加强数据库功能时,只需在该类的基础上封装所需的方法即可。
2 结论
本文针对SQL数据库的操作方式中出现的字符串容易出错的问题,采用面向对象的程序设计思想,设计了相关的访问模式,实践证明,这种方式行之有效。
参考文献
[1]马骏.c#网络应用编程基础[M].北京:人民邮电出版社,2006.
数据访问模式 篇6
企业有一05年度开发的管理系统,当时采用JSP+JavaBean架构,因受个人能力有限,虽然实现了逻辑功能和显示功能的分离,但是由于视图层和控制层都是由JSP页面实现的,即视图层和控制层没有实现分离,仍属于传统Model1模式,不符和MVC开发原则。因该软件目前整体运行情况良好,满足企业需求,想在不改变软件行为的前提下,对软件内部结构及代码进行重构,使管理系统符合J2EE技术标准,提高代码其可阅读性,实现软件更大粒度的复用。
因重构内容较多(涉及到UI层,业务逻辑层,数据持久层、域对象层等内容),现仅以系统重构前后如何适应多数据库为例进行说明。
2 旧系统数据库连接简介
系统数据库连接方式采用数据库厂商提供的专用驱动程序,通过JDBC API调用转换为直接网络调用,实现数据库连接,个人认为这种调用方式一般性能比较好,而且也是实用中最简单的方法。
为适应多数据库访问,旧系统实现原理:应用程序(javabean、SEVLET等)—>读取配置文件->JDBC API驱动程序->访问数据库(MYSQL、SQL2000);
2.1 读取dbconfig.property配置文件,获得数据库连接信息(Property文件内容见下)
2.2 根据读取DBType值来判断数据库连接类型
2.3 调用API函数建立数据库连接
3 问题的提出
该系统中数据库访问逻辑代码没有放在视图层中,但视图层和控制层都是由JSP页面实现的,即视图层和控制层没有实现分离,属于Model1模式。随着企业规模的不断扩大,业务逻辑规则不断添加,维护难度增加,旧系统的缺陷是明显的,例如业务规则和模型代码混合在一起,这类代码依赖性使应用程序在在添加业务规则时非常麻烦;大粒度的软件复用几乎不可能。
在软件工程领域,为了降低模块耦合度,提高模块的可重用性,分层一直是广为采纳的一个方法。Model2模式———MVC开发模式克服了Model1存在的不足,MVC的具体含义是:model+view+control,即模型+视图+控制,这样的模式集成了JSP、Serclet、JavaBean,非常适合大型项目的开发,具有良好的伸缩性和扩展性。
按照MVC的设计原则,层与层之间应该保持相对独立,数据的传递在不同的层之间通常利用Java Bean来创建数据传输对象(Data Transfer Object,简称DTO),从技术的角度上面来说,有几个优点:
1)采用DTO来传输数据可以减少传输数据的冗余,提高传输效率,更重要的是实现了各个层之间的独立,使每个层分工明确。模型层负责业务逻辑,视图层负责向用户展示模型状态。
2)采用DTO,模型层对视图层屏蔽了业务逻辑细节,向视图层提供可以直接显示给用户的数据。在一个规范的J2EE架构中,不同层的数据表示应该被限制在层内,而不应该扩散到其它层,这样可以降低层间的耦合性,提高J2EE架构整体的可维护性和可扩展性。比如说Web层的逻辑进行了修改,那么只需要修改Web层的Form Bean结构,而不需要触动业务层和持久层的代码修改。同样的,当数据库表进行了小的调整,那么也只需要修改持久层数据表示,而不需要触动业务层代码和Web层代码。
结合项目中如何适应多数据库问题,决定使用DAO(DATA Access objiect)模式及工厂模式相结合的解决方案法。
4 现有系统详细说明
4.1 DAO工作模型参与者和职责
职责说明:
1)BusinessObject(业务对象):代表数据客户端,该对象需要访问数据源以获取和存储数据。
2)DataAccessObject(数据访问对象):是该模式的主要对象。DataAccessObject抽取该BusinessObject的低层数据访问实现,以保证对数据源的透明访问。BusinessObject也可以把数据加载和存储操作委托给DataAccessObject。
3)DataSource(数据源):代表数据源实现,数据源可以是不同的RDBMSR数据库、XML文件等等。
4)ValueObject(值对象):代表用做数据携带着的值对象。DataAccessObject可以使用值对象来把数据返回给客户端或客户端数据修改后传给DataAccessObject。
4.2 工厂方法模式(Factory Method)和抽象工厂模式(Abstract Factory)比较
二者都是工厂模式中的一员,都能实现让应用程序的高层模式在创建类的实例时无需依赖于这些类的具体实现,但它们有不同的适应场合。
1)抽象工厂模式(Abstract Factory)适应条件:一个系统要独立于它的产品的创建、组合和表示时;一个系统要由多个产品系列中的一个来配置时;当你要强调一系列相关的产品对象的设计以便进行联合使用时;当你提供一个产品类库,而只想显示它们的接口而不是实现时。
工厂方法模式为数据库访问类实现一个工厂方法模式是相当容易的,但如果客户要求能够选择返回数据的对象类型,那么随着更多数据提供者的增加,一个基于工厂方法模式的类模型将呈现成倍的增长,所以,工厂方法模式并不适合处理多选择的问题(多于一个参数的问题)
2)工厂方法模式(Factory Method)适应条件:当一个类不知道它所必须创建的对象的类的时候;当一个类希望由它的子类来指定它所创建的对象的时候;当类将创建对象的职责委托给多个帮助子类中的某一个,并且你指定哪一个帮助子类是代理者的时候。
抽象工厂模式(Abstract Factory)是为创建相关或相互依赖的对象族提供一个接口,而无需为这些对象指定具体的类。如果应用到我们的数据层组件,每个数据提供者可以看成一个族,每个族的成员都是一个具体的类,很显然,抽象工厂模式更适合多个参数(数据库)的问题。
4.3 采取抽象工厂模式的DAO模型
通过调整抽象工厂和工厂方法模式,DAO模式可以达到很高的灵活度:使用DAO模式来抽象和封装所有对数据源的访问;DAO管理着所有与数据源的连接以便于检索和存储数据;DAO完全向客户隐藏了数据源的实现的细节。由于当底层数据源实现变化时,DAO向客户端业务组件提供的接口不会变化,所以该模式允许DAO调整到不同的存储模式,而不会影响到客户端组件。DAO模式充当了组件和数据源之间的适配器。当低层存储随着实现变化而变化时,可以使用抽象工厂方法模式实现多数据库适应问题。
具体类图见下:
下面对图所示的结构元素进行解释:
AbstractDAOFactory是一接口对象,该对象可以构造多种类型的DAO工厂接口,每个工厂支持一种不同类型的持久性存储实现(数据源),例如XML文件、MYSQL、ORACLE等,AbstractDAOFactory中,都有一个返回新产品对象的方法,如我们定义的CreatAbstractDAO方法等客户端组件正是通过这些方法来获得DAO实例,但客户端组件并不知道它们正使用的是哪些具体的对象,这样客户端组件就不会依赖于具体的DAO,从而不依赖于具体的数据源实现。
XmlDAOFactory、RdbDAOFactory:根据数据源的不同设计了两个DAO接口对象,继承自AbstractDAOFactory。
MysqlDao、OracleDao:这两个具体DAO工厂对象实现了RdbDAOFactory接口,以支持和实现有关的访问。
4.4 部分实现代码
系统开发环境:Eclipse3.3+MYECLIPSE6.0GA+Tomcat5.5.24+jdk1.6;采用开源框架Spring+Struts+Hibernate实现MVC架构。
以MYSQL数据库为例,根据前面建的DAO数据层组件模型,需要创建一个AbstractDaoFactory接口、一个RdbDaoFactory接口和MYSQL数据库对应的MysqlDao工厂类,这种结构来自于抽象工厂设计模式。通过对异类数据源的访问提供了统一的接口,用户针对不同的数据源,只需在配置文件里面修改相应的数据源类型,就可以应用同一个应用系统来访问不同的数据源了。
在JAVA开发环境下,不同数据库访问机制基本相同,不同之处在于命名空间不同,每个命名空间下的类的实现基本相同。基于这个原因,我们可生成MYSQL、Oracle等数据源的访问代码,然后根据需要把这些生成的代码进行修改组合,最后生成我们的数据层组件模型的代码。
RdbDaoFactory关系数据库接口代码如下:
建立相应命名空间下的具体工厂类,下面我们分别建立针对MYSQL和Oracle数据源下的具体工厂类,MYSQL数据源的MysqlDao具体工厂类代码为:
其它数据源的具体工厂类实现代码和上面的类似。
在对具体数据库进行操作时,我们需要实例化针对数据源的访问类,这时我们只要从xml配置文件读出数据源类型,生成相应的访问类就可以对数据源进行操作了。数据源类型判断代码:
5 结论
该企业信息系统重构后已经投入运行,并且取得了很好的效果。重构后数据库访问层组件模型隐藏了在数据库中存取对象的细节,使得业务逻辑层独立于具体的数据模型和数据库产品,而且把设计模式应用于数据层组件模型,使得该模型具有更好的伸缩性和扩展性。
参考文献
[1]阎宏.Java与模式[M].北京:电子工业出版社,2002.
[2]Richard Hightower,Nicholas Lesiecki.JAVA极限编程[M].北京:机械工业出版社,2004.
[3]Mike o'Docherty.面向对象分析与设计(UML.2.0版)[M].北京:清华大学出版社,2006.
[4]陈樟洪.IBM Rational Software Architect建模[M].北京:电子工业出版社,2008.
[5]曹广鑫.Java企业级开发项目实践[M].北京:清华大学出版社,2004.
数据访问模式 篇7
关键词：B/S模式网络,异步数据访问,NET平台,同步访问,并行访问
在B/S模式网络中, 应用程序经常需要从后台数据库服务器中读取一个大型的数据文件, 与此同时它还需要处理来自前端浏览器的请求。传统的文件访问都采用同步方法来处理这个问题, 即在文件输入输出进程中应用程序处于等待的状态。在.NET平台中, 可以通过创建后台数据处理线程的方法实现异步数据访问。
1 异步数据访问的基本思想
异步数据访问是.NET框架的许多区域都支持的功能, 例如:文件IO、流 IO、套接字 IO以及使用ASP.NET创建的XML Web services等。如果需要使用文件IO的异步数据访问, 首先需要创建的后台处理线程有启动文件输入输出进程的能力, 并且在运行这些进程的同时继续处理来自前台浏览器的请求。当输入输出进程结束时, 它会通知应用程序。使用这个方法, 可以实现前台和后台并行工作的状态。
.Net Framwork为异步操作提供了两种操作模式:使用IAsyncResult对象的异步操作或使用事件的异步操作。使用IAsyncResult设计模式的异步操作是通过Begin操作名称和End操作名称来实现。Begin操作名称方法开始异步操作, 并返回一个实现了IAsyncResult接口的对象。End操作名称方法可结束异步操作。如果调用End操作名称时IAsyncResult对象的异步操作还没有完成, 则End操作名称将在异步操作完成之前阻止调用线程。
在异步操作完成之前阻止应用程序有以下方法:从应用程序的主线程调用End操作名称, 阻止应用程序执行, 直到异步操作完成之后再继续执行, 或者使用AsyncWaitHandler阻止应用程序执行, 直到一个或多个操作完成之后再继续执行。
异步操作完成时不需要阻止应用程序可以用以下方法:定期检查IsCompleted属性, 操作完成后就调用End操作名称, 或者使用AsyncCallback委托来指定操作完成时要调用的方法。
FileStream类提供了BeginRead和EndRead方法从文件中异步读取字节。
2 异步数据访问过程的实现
2.1 异步数据读取
以一个指定文本文件内容读入内存为例, 说明此过程。首先在VS.NET中, 将默认类更名为ReadAsync;然后在Main方法中创建ReadAsync类的实例;最后创建ReadAsync类的构造函数。应用程序的大部分工作都在该构造函数中完成, 它首先检查是否确实存在该文件;然后使用FileInfo的OpenRead () 方法实例化FileStream对象;再设置用于从文件异步读取数据的参数, 开始数据的读取。数据读取通过FileStream类的BeginRead () 方法实现, 其格式为:
IAsyncResult BeginRead (byte[ ] array, int offset, int numBytes,
_AsyncCallback userCallback, object stateObject) ;
其中, userCallback是用户自己编写的代理方法, 当应用程序读取数据结束时, .NET将回叫应用程序;stateObject是用户提供的对象, 用于区分该异步读取数据请求与应用程序中其他读取数据请求。
2.2 异步数据写入
将数据异步写入文件的过程与异步读取数据的过程基本相同, 主要使用FileStream类的BeginWrite () 方法完成, 其格式为:
IAsyncResult BeginWrite (byte[] array, int offset, int numBytes,
_AsyncCallback userCallback, object stateObject) ;
该方法表示从文件中的offset位置开始将numBytes个字节的数据写到文件中。userCallback是用户自己编写的代理方法, 当应用程序读取数据结束时, .NET将回叫应用程序;stateObject是用户提供的对象, 用于区分该异步写入数据请求与应用程序中其他写入数据请求。
由于数据写入和数据读出的过程基本相同, 具体代码省略。
3 结束语
对于一般应用程序而言, 数据的异步存储并不是经常用到, 但对于B/S模式的动态网站来说, 却经常需要将数据保存到后台数据库中, 或者从后台数据库中读取大量数据。异步数据存储可以快速地完成这个过程。该算法在学院网站中使用后, 速度提升效果明显。
参考文献
[1] Ferrracchia F C.NET数据服务.毛尧飞, 译.北京:清华大学出版社, 2005
[2] Blair F B R.VB.NET高级编程.张加荣, 译.北京:清华大学出版社, 2005
[3] 使用.NET异步编程, http://dev.csdn.net/article/13/13378.shtm
[4] Onion F.ASP.NET基础教程.施 诺, 译.北京:清华大学出版社, 2003
通用数据安全访问模型 篇8
本文提出了一种通用数据安全访问的模型CDSA, 它实现数据的抽象访问与同步, 帮助工程师们管理好系统软件的数据, 保持数据的一致性和完整性。基于此模型可以实现远程过程调用 (RPC) , 其机制、原理和标准的RPC调用以及分布式计算原理完全相同, 不同之处在于这种调用方式可用于跨进程、跨系统、跨计算机边界、跨平台等复杂的环境中。
1 通用数据安全访问模型
首先, CDSA模型把各种系统软件对公用数据的访问划分为高级访问 (调用者需要理解数据以及各参数和返回的含义) 和原始访问 (调用者无需理解数据以及各参数和返回的含义) 。高级访问针对数据应用, 原始访问针对数据传递过程。
(1) 原始接口:输入和输出为数据流, 不理解协议本身以及任何应用数据结构, 供通讯使用。
(2) 高级接口:输入和输出为实际应用数据, 理解协议本身以及应用数据结构, 供业务使用。
其次, 考虑到一般的系统软件中数据的传递过程分为进程组内部数据传送 (交换) 和远程数据交换, CDSA模型规定进程组内的数据传送通过消息队列进行通讯, 在进程组外的数据传送, 主要通过SOCKET进行通讯。CDSA模型还约定这两种数据传输均通过原始模式进行, 不需要理解数据的含义以及输入和返回。
(1) 对于本地应用进程 (服务器进程) , 通过消息队列和主进程进行通讯, 达到数据读写的目的。为什么这样处理呢?主要是因为CDSA模型支持保存复杂的数据结构, 而共享内存只能适用于简单的数据结构, 如果采用复杂数据结构, 必须实现空间管理, 这非常复杂且可移植性不强。
(2) 对于其他进程, CDSA选用SOCKET作为通讯的手段, 通过抽象和复用代码等方法完成完整的数据通讯和交换过程。既达到RPC的效果, 又降低系统复杂程度, 同时满足了高效数据通讯的需求。
(3) CDSA模型规定, 服务器启动后, 主进程负责将全部的数据加载到内存, 主进程有义务通过消息队列或SOCKET等方式为其他服务进程 (包括远程管理进程、客户端进程) 提供数据共享, 并惟一直接操作数据库, 以维持数据的统一性。
(4) 如果系统软件有独立的远程管理进程, 由于多次远程读取数据需要耗费大量的带宽和时间, 所以CDSA模型规定管理端进程与服务端连接后, 首先下载并且维护一份和远程服务端一致的数据, 如此一方面保证本地数据和服务器数据的一致性, 一方面降低数据读取的消耗。
(5) CDSA为了保证数据的一致性, 采用了读取共享、写入独占的方式。具体来说, 本地应用进程在系统启动后自动获取数据库的修改权限, 第一个连接进入的管理进程可以抢占该写入权限, 直到该进程退出后, 如果系统中已经存在有一个管理连接, 后连接进入的进程将只能获取读取的权限, 并不能剥夺第一个管理进程的写入权限。
最后, CDSA模型定义数据访问的触发 (回调) 机制, 用于在设置变更或读取的状态下做出某种响应 (如配置系统、数据同步传递、数据重读、数据更新等) 。
2 CDSA模型的实现
CDSA模型存取的数据可以是数据库, 可以是配置文件、系统环境等。对数据库的操作没有定义专门类, 需要各系统软件自行考虑。对配置文件、系统环境等的存取, CDSA模型定义了实现IBoot DBIPlugin接口的Csvr Cfgtor类。通过这个专门类去处理实际的数据存取, 该专门类还支持调用IAdvBootDBI接口, 以便远程重新获取数据、远程修正数据。
CDSA模型还定义了两个实现IRaw Boot DBI或者IAdv BootDBI接口的类, 用于完成对数据的存储和数据格式的转换。
(1) 数据直接访问类
完成数据的直接访问, 对数据库进行直接操作, 通过IBoot DBIPlugin接口调用Csvr Cfgtor类来完成数据的存储以及存储的事件通知。
该类实现了IRawBootDBI、IAdvBootDBI这两个接口。其他进程可以通过这两个接口调用来存取数据。
(2) 数据中继访问类
完成数据的转换, 可以将复杂的数据结构转换为标准的数据流, 或者将数据流还原成复杂的数据结构。这些数据流包括两个部分:输入流和输出流, 通过这两个部分完成参数的传递和返回值的获取。
该类实现了IAdvBootDBI这个接口, 支持调用其他类的IRawBootDBI接口去传递、存取数据。其他进程可以通过这两个接口调用来存取数据。
(3) 客户端SOCKET类 (数据通讯模块)
数据通讯模块本身即为一个基于IRawBootDBI的对象, 他们完成的工作即将输入流送入其他服务进程或者服务器端, 然后等待其他服务进程或者服务器端返回一个输出流。一个CBootDBRelay的对象可以成功地将高级的数据转换为 (序列化) 流格式, 然后调用通讯模块的接口IRawBootDBI, 等待通讯模块完成数据请求后, 将返回流还原成 (反序列化) 高级格式, 返回给调用者。
数据通讯模块对数据的序列化与反序列化是成对出现的, 如果有多对序列化的格式, 就要分配协议号以示区别, 协议号本身被序列化成流格式的第一个字节, 反序列化时先读取第一个字节, 了解序列化的格式, 再对后续的流格式进行反序列化。
3 CDSA模型中数据访问的流程
模型中涉及配置数据的各进程对数据访问的逻辑示意如图1。
(1) 数据服务进程的直接数据访问
数据服务进程负责数据库的管理, 是数据的直接处理进程, 该进程通过消息队列实现数据的对外共享。
如图1所示, 在请求到达后, 该进程通过CBootDBDirect访问数据, 并同时完成系统配置:[消息队列服务器端]->IRawBootDBI (CBootDBDirect) ->DB (->IBootDBIPlugin (CSvr Cfgtor) ->系统配置) 。
(2) 本地进程间的数据访问
本地应用进程是本地的数据消费者之一, 该进程不能直接访问数据库的数据, 但可以通过高级访问接口存取数据:[本地应用进程]→IAdvBootDBI (CBootDBRelay) ->IRawBootDBI (消息队列客户端) 。其过程如图2所示。
(3) 远程进程间的数据访问—服务端
远程管理进程的服务端是数据的转发层, 对外衔接网络, 对内衔接数据服务进程。
[远程管理进程的服务器端]->IRawBootDBI (消息队列客户端) 其过程如图3所示。
(4) 远程进程间的数据访问-客户端
如图4所示, 远程管理客户端进程为数据的消费进程, 存在两种访问数据库的方式:
本地缓存数据:[管理]->IAdvBootDBI (CBootDBDirect) ->CacheDB
远程数据:[管理]->IAdvBootDBI (CBootDBDirect) ->IBoot DBIPlugin (Csvr Cfgtor) ->IAdvBootDBI
(CBootDBRelay) ->IRawBootDBI (SOCKET客户端)
4 CDSA模型的应用
图5说明了一个无盘站引导服务系统使用CDSA模型进行数据访问的实际情况。
说明:
(1) 图中数据守护进程不但是主无盘站引导服务软件的主进程, 还是数据服务进程, 它直接进行数据访问, 通过消息队列实现数据的对外共享。
由于系统软件本身功能不同, 操作的数据类型肯定也不同, 这就要根据实际需要去定义具体的实现类。图5中定义了无盘配置数据, 系统数据, 系统配置数据, 缓存数据等类。
(2) 图中DHCPBINL服务进程和TFTP守护进程对应了本地应用进程。
D H C P B I N L和T F T P守护进程是本地的数据消费者, FTFP还会fork出新的进程进行数据消费, 这些进程通过高级访问接口存取数据。
(3) 图中的管理服务器进程对应远程进程的服务端
管理服务器进程是数据的转发层, 对外为管理工具提供数据, 对内向数据服务进程取得数据。
(4) 图中的管理工具进程对应远程进程间的客户端
管理工具进程是数据消费进程, 刚建立连接时, 把数据从服务端请求到本地缓存, 以后的操作在缓存内进行。操作完成后, 如果缓存数据被修改过, 就调用CsvrCfgtor类的IBoot DBIPlugin接口回写数据。也可以通过IBoot DBIPlugin接口从远程取得最新的数据。
摘要：本文提出了一个称为CDSA的数据安全访问模型, 该模型可以被用在各应用软件中保证服务端与客户端数据的一致性, 也可以用在本地进程间通信、远程进程间通信等领域, 保证共享数据的一致性。
关键词：数据存取,数据一致性,回调
参考文献