基于现代方法的舌诊图象管理系统的设计与实现-学士论文

基于现代方法的舌诊图像管理系统的设计与实现 摘要 厦门大学学士学位论文基于现代方法的舌诊图象管理系统的设计与实现摘要 舌诊是中医“望”的步骤之一，舌诊的诊断主要根据舌体、舌的动态和舌下脉络的医理特征进行。一张舌诊图象对应的诊断信息较多，在有大量可参考的图片时，用操作系统的文件目录管理将造成很大的不便。需要对舌象进行研究的中医学工作者、中医专家系统的设计者需要一个集中的平台来管理舌诊图像。舌诊图像管理系统将舌诊图像与其相关资料入库，可以进行修改、查询、删除等操作，以支持使用该系统的用户进行后续的有关舌诊图像处理的研究。本文基于数据库应用软件设计的N层模型探讨中医舌诊图像管理系统的构建。N层模型已经是发展得很成熟的模型。本文的主旨是在应用这一成熟的软件开发模型的基础上，论述如何在构建系统的方方面面，吸收并应用最新的软件工程、软件设计方法学思想，以达到更好的软件设计与开发实践，进而提高软件的质量。舌诊图像管理系统在构建过程中借鉴了如下的设计方法：以工厂方法构建数据访问层；以单元测试保证代码质量；以重构优化软件结构；以Humble Dialog模型优化表示层的设计。这些设计方法也是本文论述的重心。关键词 中医舌诊 N层模型 数据库应用软件 .Net 模式 极限编程 Humble DialogModern-method-based Design and Implementation of Lingual Diagnostic Images Management SystemAbstractLingual diagnose is one of the observation steps in Chinese Medicine, lingual diagnose is based on diagnostic information of lingual itself, its movement and bottom venation. A single lingual diagnose image may be companied by much diagnostic information; using OS folder to manage all of the images would be unhandy in the situation with a lot of them. Chinese Medicine researchers and Chinese Medicine expert system designers whose jobs call for lingual diagnostic images need a central system to manage all the images. A lingual diagnostic management system supports its users to go on with their researches by storing these images and other operations such as update, search and delete.This article discusses the implementation process of a lingual diagnostic management system, and is based on N-tier model of DB application which is a matured model. While applying this model, this article probes how to use the latest new theories of software engineering and design methodology in every aspect of system development, to achieve better design and development practice, and to improve software quality.This system references the following design theories in development process: Factory Method to construct Data Access Layer, Unit testing to assure codes quality, Refactoring to improve software structure, and Humble Dialog to better presentation layer design. These design methods are the focus of this article.Keyword: Lingual diagnose， N-tier Model，Database application， .Net， Patterns， eXtreme Programming， Humble Dialog- 34 -基于现代方法的舌诊图像管理系统的设计与实现 目录 厦门大学学士学位论文目 录引 言10.1 研究背景10.2 建立舌诊图像管理系统的意义10.3 论文结构1第一章中医学舌诊与舌像管理31.1中医学中的舌诊31.1.1舌诊基于舌的结构31.1.2舌诊的临床意义31.2需求的简要描述31.3本项目设计与实现过程使用的软件3第二章用工厂方法构造数据访问层52.1数据库应用程序N层模型52.2面向对象的数据库开发52.3项目中DAL的具体设计62.3.1解决方案布局62.3.2设计商业实体72.3.3实现DAL8第三章应用设计模式133.1应用Factory method133.1.1为何使用Factory Method133.1.2使用Factory Method带来的灵活性143.2应用Singleton143.2.1为何使用Singleton143.2.2对Singleton实现方法的修改153.3应用Facade15第四章实行单元测试与重构提高软件质量174.1XP简介174.2项目中的单元测试174.2.1单元测试新思维174.2.2有关用例设计的分析184.2.3结合NUnit2.0框架进行单元测试184.3重构代码214.3.1重构改善既有代码的设计214.3.2重构数据访问层224.3.3重构工具引起的话题23第五章Humble Dialog方法与GUI层设计245.1使用Humble Dialog方法构建表示层245.2新方法带来的增益275.3评价Humble Dialog方法29结 语30致 谢31参 考 资 料32基于现代方法的舌诊图像管理系统的设计与实现 引言 厦门大学学士学位论文引 言设计中国传统医学的计算机专家系统是信息时代中医学自我发展、面向未来的一个新契机。中医专家系统的设计出发点是及时、科学地利用计算机信息网络技术，服务于中医，发展中医，弘扬传播中医药学；科学、高效地开发利用中医药学术资源，实现中医药信息管理与应用计算机化，实现专业资源共享；加快中医药学科创新。在充分运用当今人工智能及其相关技术的最新进展提供的新理论、新方法和新技术的基础上，中医中药的现代化、信息化发展将能开拓出一条新途径。0.1 研究背景目前，国内外有关中医信息系统的研究，整体上水平比较低，离实用化要求还有很大距离，特别是有关智能中医信息处理技术，由于存在一定的技术难度，进展比较缓慢。随着人工智能新技术的不断发展，特别是先进逻辑推理技术、软计算方法、数据挖掘技术、图象视频技术、多通道传感器技术、多主体系统方法、自然语言处理技术等的发展，为全面开展智能中医信息技术的研究奠定了理论、方法与技术的基础。就中医舌诊的研究而言，如何利用最新提出的一些人工智能新技术，特别是软计算技术、自然语言处理技术、数据挖掘技术、图象获取与处理技术、次协调逻辑与认知缺省逻辑等，结合中医舌诊丰富的临床经验和病历数据，来开展基于舌诊的智能诊断系统的研究开发，不仅十分必要，也是完全可能的。0.2 建立舌诊图像管理系统的意义一张舌诊图像的对应信息是比较多的。最简单的舌像信息管理方法是采用操作系统目录的形式进行管理。比如：一张典型的描述淡红舌的舌像图片可以放置在“舌体颜色红舌淡红舌”目录下。但是这种方法依赖研究人员手工管理，查询相关资料也不方便。如果例子中的这张舌像同时有典型的“剥苔”的特征，那么“舌苔形质剥苔”目录下同样需要保留一份拷贝；如果其中的一张资料进行更改，而同名拷贝没有及时进行更新将引起保存的信息不一致。在资料数量大时，这将导致极大的不便甚至混乱。实际上完全可以编写一个管理工具软件来辅助研究人员，提供一个集中进行存储与查询的平台。这也是设计这样一个“舌诊图像管理系统”的初衷。0.3 论文结构论文主要结构和内容安排如下：第一章： 在简要介绍中医学舌诊的基础上，分析舌诊图像管理系统的设计要求，简要介绍开发过程中使用的软件。第二章： 详细介绍系统数据访问层的“工厂方法”的设计，与构建过程中的问题解决。第三章： 介绍在项目中如何应用设计模式，优化软件结构。第四章： 介绍在项目的开发过程中，贯彻极限编程单元测试与重构两种实践，最大程度地保证软件的质量。第五章： 介绍在表示层，用Humble Dialog的设计思想，分离界面相关代码与界面无关代码，使表示层的代码逻辑清晰化，以便于测试与后期的维护和改进。基于现代方法的舌诊图像管理系统的设计与实现 第一章 厦门大学学士学位论文第一章 中医学舌诊与舌像管理1.1 中医学中的舌诊1.1.1 舌诊基于舌的结构舌体是人体直接可见的内脏器官；舌诊是中医“望”的步骤之一，舌诊是通过观察舌象，了解机体生理功能和病理变化的诊察方法。在中医学舌诊过程中，医师观察患者的舌体、舌苔、舌下脉络、舌的动态，这些医理特征是由舌的肌肉、神经、粘膜、腺体等等舌的组成部分的性状共同决定的。舌体的诊断结果用下列几个医理特征加以描述：舌体颜色、舌的形质（包括荣枯、老嫩、胖瘦、点刺、裂纹）、舌苔颜色、舌苔形质（包括厚薄、润燥、腻腐、剥苔）、舌下脉络以及舌的动态。舌体依赖气血充养，是全身营养和代谢功能的反映。舌的形态和色泽与脾胃、气血直接相关。全身五脏六腑都直接或间接的通过经络、经筋与舌相联，通过望舌色可以了解人体气血运行情况。1.1.2 舌诊的临床意义舌象变化能较客观地反映病情，作为判断邪正盛衰、区别病证形质、分析病位和病势的依据，故对临床辩证、立法、处方、用药、判断疾病转归以及分析病情预后，都有十分重要的意义。1.2 需求的简要描述舌诊图像管理系统将提供一个图形化的界面，帮助研究舌诊图像的用户管理、查询舌诊图像。实现的功能很直接，即对舌诊图像提供添加、查询、修改、删除四个主要的管理模块。入库的舌象数据信息不仅包括舌像数据本身（直接存储BMP、GIF、JPG等格式的图形文件，在数据库中表现为二进制数据字段），还包括对应舌像的医理特征描述，包括如下字段：舌体颜色，苔色、形质荣枯、形质老嫩、形质胖瘦、形质点刺、形质裂纹、苔质厚薄、苔质润燥、苔质腻腐以及剥苔。考虑到可能存在恶意篡改、删除数据的行为，软件中应加入简单的用户帐号管理功能，防止数据丢失。一条舌像记录还应包括创建人、创建日期、上一次修改者、上一次修改日期等信息，以尽可能的跟踪数据的变化。此外，无特殊的非功能性需求。1.3 本项目设计与实现过程使用的软件本项目的设计实现的基础是相当成熟、并广为采用的N层开发模型。软件的最终形式是基于托管代码的桌面应用软件，采用的开发语言是C#，基于.Net Framework 1.1。开发工具如下：开发平台：MS Windows 2000 /XP编程平台：Visual Studio .Net 2003DBMS: SQL Server 2000 Service Pack 3、Oracle 9i单元测试框架：NUnit 2.0GUI测试工具：WinRunner 7.01重构工具： C# Refactoring Tool 1.0、 Resharper 0.78UML建模工具：Rational XDE for VS.Net 2003版本管理：Visual SourceSafe 6.0d 其中，单元测试框架NUnit作为动态连接库直接在项目中引用；重构工具C# Refactoring Tool和 Resharper、UML建模工具Rational XDE、版本管理工具Visual Source Safe均直接集成在VS.Net 2003的IDE主界面中；设计数据库表结构的过程需要在两套DBMS中分别进行；GUI测试WinRunner需要单独运行。基于现代方法的舌诊图像管理系统的设计与实现 第二章 厦门大学学士学位论文第二章 用工厂方法构造数据访问层2.1 数据库应用程序N层模型早期的基于数据库的应用程序采用“两层”的设计方案：表示层与数据连接层。有鉴于Smalltalk设计模式中MCV（Model/Controller/Viewer）思想的成功，传统的三层模式应运而生。这种表示层商业逻辑数据连接层的经典三层架构分离了表示与逻辑，但是数据连接层没有太大变化。从ADO等数据访问组件流行开始，程序员从数据库连接的繁琐编程中极大地解脱出来，因为编写数据库连接代码时，可以不考虑具体的DBMS产品的林林总总的不同的细节，可以直接用抽象数据库的思维调用数据访问组件。无论N层模型设计上如何变化，数据层以上并没有多大悬念，而技术上最反复多变的莫过于数据层。实际上，对程序员来说，编写数据层是最让人畏惧的，原因倒不是DAL采用的技术有多难；恰恰相反，多数程序员认为这是最没有技术含量的一个部分。这一层的开发时间并不长，但的的确确是苦差事，因为开发DAL的过程相当于把DBA的工作重新做过一次，即使有了ADO、ADO.NET等等数据访问组件，少不了还是得映射数据表中的字段到商业实体对象的各个属性。出于程序架构设计的原因，模型中加入DAL层。DAL层基于被广为接受的数据访问组件，对传统的架构模式提出了巨大的挑战，加入的目的肯定也是为了进一步提高生产效率。我们现在谈到N层模型，主要是表示层商业逻辑数据访问层（下文起简称DAL）这种三层架构，以及由它再细化出来的多层模型，有别于传统三层模型的直接基于DB访问API的编程方式。下图便是现在很常见的数据库应用程序的设计模型：图1 基于数据库的应用程序的设计模型2.2 面向对象的数据库开发在理想的情况下，所有的程序员都希望写程序时彻底斩断同数据库藕断丝连的关系，永永远远同SQL语句说再见，可以写出这样的代码：AccountDAL.InsertAccount( Account acc );程序员只管传递一个对象，至于后台DB是Oracle、SQL Server抑或是DB2，还有如何将对象的属性保存到数据库等等操作可以由某个解决方案提供，程序员完全不理会个中细节。但是，目前绝大多数的项目采用基于数据访问组件（比如ADO、ADO.Net等等）的方法进行开发，这将意味着数据表现层与数据库表紧耦合，这样构建的系统的可扩展性与可维护性都不尽如人意。而在开发期间，程序员用类似这样的语句从数据集中读取数据时，编译器无法检查类型是否匹配，SqlDataReader dr = ;int aNumber = dr.GetInt32(3);/ 读取表的第三列，读取的结果作为整形数这样的错误只有在运行时以错误、异常的形式抛出；在这一点上，基于数据访问组件的解决方案还没有有效的解决方法。近年来，越来越多的人认识到使用面向对象的数据库开发框架进行数据库应用的开发有许多的好处。在项目设计阶段，使用UML建模设计业务域对象模型；再从模型出发，使用开发组件对业务域对象进行操作，设计某些方法将业务对象保存到数据库，或者从数据库加载；这就是通常所说的O/R Mapping对象关系映射。面向对象的数据库开发框架支持对象查询语言OCL，并具有如下功能：对象连续性、对象查询、对象主键、支持XML、支持多种应用、兼容已有数据访问组件等等。目前在.Net平台，除了第三方的开源项目外，较有名的模型驱动的面向对象的数据库开发框架/解决方案有微软的ObjectSpace和Borland的ECO（Enterprise Core Object）。微软的ObjectSpace将在Visual Studio .Net Whidbey (VS.Net 2003的后继版本)和 SQL Server Yukon（SQL Server 2000的后继版本）中得以支持，目前是测试版本；Borland的ECO是比较成熟的解决方案，但只在C# Builder 1.0 Architect和Delphi 8.0 Architect中得到支持。并且ECO是商品化的软件，不像ObjectSpace那样下载.Net Framework就可以使用。基于上述的原因，本系统DAL的开发是基于数据访问组件ADO.Net进行，没有采用面向对象的数据持久技术。2.3 项目中DAL的具体设计2.3.1 解决方案布局在舌诊图像管理系统中，DAL层的最终设计方案支持多数据库，目前支持SQL Server和Oracle这两套流行的DBMS，在BLL访问DAL时无需对不同的数据库做特殊处理，BLL只管在表示层与DAL之间传递对象；即便以后加入对DB2或其它数据库系统的支持，在BLL层编写代码时仍然所有帮派一视同仁，不需改动已有代码。项目中实际的设计方案如图2所示。图2 本项目的设计模型图3给出本项目在VS.Net 2003中的解决方案布局，设计模型中的每一个元素在解决方案中用对应的Project表示，所有的类均清晰地划分其归属。图中各Project的简要描述在表1中列出。图3 VS.Net 2003中的解决方案布局.NET 实现说明WinApp表示层窗体ConfigTool连接设置工具PostSetup安装后配置脚本BLL商业逻辑层DALFactoryDAL工厂IDALDAL层公共接口SqlServerDAL连接SQL Server的DALOracle连接Oracle的DALModel描述所有Business EntityUtilities各层通用的公共代码表1 图二解决方案布局的说明DAL层的设计采用了“工厂方法”的设计模式（Factory Method Pattern），这一模式的应用将在下文“3.1 应用Factory Method”中详细讨论。2.3.2 设计商业实体图2中贯穿各层的是“商业实体”（Business Entity，也就是用户操作进行时信息存储的实体对象，如设计网上书店时的Customer、Book、Order，本系统程序中的用户信息AccountInfo、舌诊图像LigualImageInfo等等）。这里的商业实体采用DataSet的设计，Account和LigualImage都是DataSet，它们在内存中的逻辑结构在一定程度上可以认为就是关系数据库理论中的表结构，连接数据库时使用DataAdapter将两者映射关联即可。DataSet源于早年微软内存数据库的设计思想，即内存中数据对象的组织方式采用关系数据库的表的设计思想，那时这种思想太过超前，又受到硬件规格的制约，因此乏人问津；在.Net时代，DataSet终于开始流行。一般而言，使用DataReader或是DataSet没有绝对的标准，可以借鉴如下几条使用原则：(1) 对资源要求苛刻的场合，这里的资源指服务器计算能力、内存和数据库连接性能等等。DataSet数据结构都包含对数据字段的操作方法，不仅仅包含数据字段；而使用DataReader的话，相应的数据实体类将会是轻量级的Structure/class，这种自定义的对象只有数据属性而没有操作，读取和存储的操作由程序员结合DataReader进行。使用上，后者将会更有性能优势。(2) 希望读取的数据可以进一步进行自定义处理时，这是典型的使用DataReader而非DataSet的理由。(3) 只希望返回部分字段，或是受操作影响的记录数。就本系统而言，添加记录的操作用的是DataReader，其它的操作（查询、修改、删除）都是使用DataSet实现的。首先是因为在数据库中设计中使用了保留字段。目前这些保留字段未使用，一旦需要增加新的医理特征描述，可以直接使用保留字段而无需调整表的结构。另外，进行插入记录的事务时，需要根据返回的记录ID号和错误码判断事务是否成功，如果分配的ID号大于0并且错误数为0，那么事务成功，程序可以提交事务（commit）；否则，事务回滚(rollback)。如果这里非使用DataSet不可，那么需要一个特殊的表，一个字段存储返回的ID，另一个字段存储存储错误码，这样的做法有一种为DataSet而DataSet的味道。当然使用DataReader虽然可以不用建立临时表存储返回结果，却必须手工映射记录的所有字段到数据库表的各字段，就不能借助DataAdapter自动映射了。两种方法各有利弊。2.3.3 实现DAL下面以添加舌诊图像为例，详细说明DAL的运作方式。用户指定要添加的图片，并对其作出医理特征说明（如淡红舌、黄腻苔等）后，点击“添加”按钮。这时数据操作行为需要发生，数据工厂从config文件中读取configuration/app/add路径下的键为DAL的设定值，如果值为“IDC.SqlServerDAL”，那么程序连接SQL Server数据库，如果是“IDC.OracleDAL”，那么程序连接Oracle数据库，依此类推。config文件的部分内容如下所示，其中key=SqlConnString 的节点的value属性值为加密字符串。config文件的配置无需手工进行，图3的ConfigTool Project编写的就是一个GUI界面的程序运行参数设置工具。用户只需输入相应信息，这些信息将自动以程序可接受的格式保存在config文件中。ConfigTool.exe的运行界面如图4所示：图4 配置工具ConfigTool.exe读取到数据库连接信息后，程序调用工厂动态绑定DAL层的组件。DataFactory层的LingualImage工厂类的代码如下所示：public class LingualImage/ 这里同时使用了“工厂方法”与“单件”两种设计模式public static ILingualImage Create( ) if( iimg!=null ) return iimg; / 查询config文件，确定需要生成的DAL组件名 string path = System.Configuration.ConfigurationSettings.AppSettingsDAL; string className = path + .LingualImage; / 使用反射，生成需要的组件 iimg = ( LDI.IDAL.ILingualImage ) Assembly.Load( path ).CreateInstance( className ); return iimg;protected LingualImage( ) private static LDI.IDAL.ILingualImage iimg;静态方法Create 返回的是借助“工厂方法”模式和.Net反射（Reflection）实时生成的组件LDI.SQLServerDAL.dll或是LDI.OracleDAL.dll的运行时对象。两个组件中的LingualImage类各自实现对不同数据库的访问操作，它们的共同行为是由IDAL层的接口ILingualImage定义的。这样，上层的代码需要进行数据库操作时，访问代码是这样的：/ 插入img中的图像信息到数据库，img是DataSet子类LingualImageInfo的实例对象DALFactory.LingualImage.Create( ).Insert( img, out imgIDs );/ 根据关键字检索图像DALFactory.LingualImage.Create( ).SearchByKeywords( keywords );可以看出，上层的代码可以写得很抽象，进行数据操作只要写一行代码就够了。在我们日常用语中，“说得很抽象”的言外之意是：不够明确、太含糊、流于泛泛之谈等等，是多少带着贬义的。相反地，程序设计时，写的代码“抽象”意思是正面的，表示模块间松散耦合、防止“硬编码” 、没有Bulk Method等等。但是高层的抽象与轻松实现是由于具体的DAL解决了那些繁琐拖沓的细节处理问题的原因。在工厂正确的生成了DAL对象之后，调用其Insert方法完成图像的入库操作。这里对SqlServerDAL.Insert进行分析,它的签名/型构如下：public bool Insert( LingualImageInfo img, out int imgIDs )列出SqlServerDAL.Insert方法中最主要的代码如下：try SqlCommand cmd = new SqlCommand( );/ 指定SqlCommand的连接和事务，读者不必深究conn和trans的声明细节cmd.Connection = conn;cmd.Transaction = trans;cmd.CommandType = CommandType.Text;/ 类的私有方法MakeInsertSQLString( ) 生成插入操作所需的SQL语句，生成的语句形如：/ Declare ID int; Declare ERR int;/ INSERT INTO LingualImages( ColumnName1, ) Values( param1, )/ SELECT ID = IDENTITY; SELECT ERR = ERROR; / SELECT ID, ERR;cmd.CommandText = MakeInsertSQLString( img ); for(int i = 0; i img.Rows.Count; i+) / 设置SqlCommand的传入参数，参数名称出现在上述SQL语句的Values子句中 SetInsertParameters( insertImgParms, img, i );/ 读取SQL语句的执行结果，返回ImgID和错误计数 SqlDataReader rdr = cmd.ExecuteReader( ); rdr.Read( ); / 正确执行SQL语句的情况下，ImgID大于0并且错误数为0 if ( rdr.GetInt32(1) != 0 | rdr.GetInt32(0) = 0 ) throw new Exception( 插入图片资料的操作失败，事务滚回 ); / ImgID作为参数返回 imgIDsi = rdr.GetInt32(0); rdr.Close( ); / 这里省略插入操作全部执行完毕后的house-keeping代码 catch( Exception e ) if( trans != null ) trans.Rollback( );throw e;相对于BLL的“一句话操作”，可以看到调用ADO.Net组件时仍不可避免的罗罗嗦嗦的代码都封闭在DAL层了。这里给出的是访问SQL Server的代码，访问Oracle的DAL层代码原理相同，不再赘述。2.3.4 有关存储过程的讨论需要说明一点的是，本项目没有采用存储过程的设计。存储过程可以极大地提高数据访问的速度，因为存储过程不再是一组SQL语句，而是针对不同数据库系统编译好的代码，还有诸如启用事务管理、减少频繁传输SQL语句等等优点。但是，设计DAL的出发点是基于程序对DAL的具体性能要求的考量，适当的设计要比过度设计理性的多。就这个系统而言，远远未到对执行速度有苛刻要求的地步；相对地，系统如何设计以满足易扩展、易维护、结构清晰、易于使用的要求则更为重要。像是China-pub、当当这样的高点击率的站点，速度的考量才确实是首要的。虽说存储过程的设计并非必须，但是基于“尽量做到更好”的设计思想，是不是应当考虑采用存储过程的设计呢？如果采用存储过程，开发的进度可能需要原来的两倍！这个估计不一定百分百准确，但绝对有根据。主流数据库产品在SQL语言的支持上差异较小（差异还是有，但是开发商都会尽量参考SQL-99标准，不至于出现面目全非的差异），但是存储过程的设计可以说完全由数据库开发商为其产品定身度造，如果DAL需要对多个DBMS同时提供支持，那就需要在各个数据库平台分别编写同名的存储过程。SQL Server和Oracle这两个平台的存储过程用途相近，但在语法上有极大的差异，设计思想、采用的技术（如游标、触发器）、错误捕捉等等实现上都大相径庭。如果单纯使用SQL语句传递访问命令，确确实实能尽可能的缩小平台差异性。再者，数据库系统本身对存储过程的调试可没有什么IDE、断点调试的支持（当然，第三方产商确实有专门为DBA提供的编写存储过程的开发环境，但是价格不菲），如果存储过程执行失败一般就弹出个警告或是异常的说明，debug起来很费心力。基于种种原因，本项目中DAL采用SQL语句来传递DB访问命令，以避免在项目的绝大部分时间程序员扮演DBA的角色。如果在后续版本中确确实实需要存储过程来加快数据访问，在程序的代码部分可以按如下方法改进。这是项目中的代码：cmd.CommandType = CommandType.Text;cmd.CommandText = aCertainSqlClauseString;将这些传递SQL命令的代码改为形如下面的代码：cmd.CommandType = CommandType.StoredProcedure;cmd.CommandText = aCertainStoredProcedureName;然后去掉所有和SQL语句有关的代码，因为实际操作转移到存储过程中，SQL语句已不再需要。需要修改的代码很少，而且不需要改变测试用例；如果单元测试用例已经很好地编写成测试脚本，只需要再次启动测试脚本即可。基于现代方法的舌诊图像管理系统的设计与实现 第三章 厦门大学学士学位论文第三章 应用设计模式项目中应用的设计模式主要有Factory method、Singleton和Faade。3.1 应用Factory methodGoF在Design Patterns一书中，对Factory method是这样说明的：图5 标准的Factory method实现Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. 定义一个用于创建对象的接口，让子类决定实例化哪一个产品子类。Factory Method使得一个类的实例化延迟到其子类。3.1.1 为何使用Factory MethodFactory Method适用于如下情况：(1) 当一个类不知道它必须创建的对象所属的类的时候。(2) 当一个类希望由它的子类来制定它所创建的对象的时候。(3) 当类将创建对象的职责委托给多个Helper子类中的某一个，并且设计者希望将“某个Helper子类是代理者”这一信息局部化时。项目中的DAL层力求避免DAL与其之上的层“硬编码”，而在数据访问行为发生时动态地调用组件，符合第一个使用情况。本项目DAL层的实际设计表示如图6所示。图6 项目中DAL层的实际设计3.1.2 使用Factory Method带来的灵活性设计一个项目的延续场景来说明使用Factory Method带来的灵活性。如果系统需要转换数据库环境，比如使用IBM的DB2，那么部署步骤如下：(1) 在DB2数据库服务器端正确设置LingualDiagImages数据库；(2) 拷贝可运行的LDI.DB2DAL.dll动态链接库文件到系统的安装目录；(3) 使用更新版本的ConfigTool工具修改配置，用它来改变config文件Configuration/appSettings/add路径下的相关键的键值。此外不需要其它的操作。因为在运行时，系统读取config文件DAL的设定值，并动态地绑定需要使用的DAL层组件，保证了对数据库系统支持的良好可扩展性。3.