实现界面和业务的分离

刘艺作品试读 china-pub 348第8章 实现界面和业务的分离8.1 关于界面和业务的分离 界面GUI 和业务Business 的分离是开发可维护易扩展长寿命的应用系统的关键也是实现多层分布式系统的必经之路面向对象编程技术为开发界面和业务分离的系统提供了行之有效的途径8.1.1 从封装到界面和业务分离 前面我们讨论了代码的封装技术在逻辑上代码的封装是通过类来实现的类通过属性封装了对象的数据类通过方法封装了对象的行为在物理上代码的封装是通过不同结构和形式的文件来实现的对于Windows应用程序代码程序可以封装在可执行文件中.exe 动态链接库中.dll 也可以封装在COM+组件中 对代码或程序的封装其目的在于实现易开发可维护能复用的软件模式因为现代软件工业已经不再是过去那种依靠一两个软件英雄通过手工作坊式的编程来完成订单的模式对大型软件项目而言只有进行科学完善的系统分析和设计将功能不断细分并通过代码的封装技术提高封装对象的可复用性可维护性才能适应日益复杂的业务上和性能上的需求 在目前主流的应用程序设计中我们可以发现具有界面和业务分层设计的系统往往更具有维护和扩展方面的优势从早期的客户机服务器系统到流行的多层分布式系统其核心思想都是强调了界面和业务的分离几乎所有的程序员都知道程序界面和业务逻辑分离的好处但在如何实现程序界面和业务逻辑分离的问题上不少程序员却很为难甚至有人还会有这样的疑问y 如何实现分离分离模块之间如何通信y 实现分离会不会让我放弃RAD 比如我无法方便地使用数据库控件y 实现分离会不会很难需要写很多代码吗 第一个问题显然是从传统的面向过程思维来看待分离其实以前程序员也努力将程序分解成模块并通过函数来彼此调用但彼此通信一直是个头疼的问题特别是设计良好的分离模块需要保持内部紧聚合外部松耦合实现不太容易但在OOP 中我们的眼中只有对象对象之间存在灵活有效的通信机制对象在逻辑上就是离散的封装良好的功能模块所以无论是实现分离还是彼此通信都很容易 第二个问题比较有代表性大多数速成的程序员都是从拖放控件起家的RAD 快速应用程序开发本身并没有错问题是编程不能只依赖于RAD Delphi 专家Marco Cantu说Choosing object-oriented programming means leaving some visual programming practices behind you.这意味着我们需要找到RAD 和OOP 之间的平衡点以面向对象的思维方式来利用RAD 因为Delphi 不是C++我们不会放弃RAD 后面大家会看到这样的例子 第三个问题我觉得是个信心的问题如果我们注意学习新技术新方法实际上很多看似很难的东西并不可怕Delphi 为我们提供了很多帮助使得我们不用写很多代码但其中仍然有很多窍门需要去学刘艺作品试读 china-pub 349 后面我通过具体的示例程序来讲解如何实现程序界面和业务逻辑的分离从这个例子读者可以看到界面和业务分离的演化过程8.1.2 从界面和业务分离到分布式多层体系结构 一个设计良好的应用程序在逻辑上应该至少划分为界面和业务两个层次界面和业务的分离将十分有利于系统的维护和扩展体现灵活复用的风格一个面向对象的程序比传统的面向函数和过程的程序更易于实现界面和业务的分离 首先对于GUI 界面不少优秀的开发工具都以面向对象的类库封装了大量复杂的API我们可以在VCL 这样庞大精致的类库支持下通过GUI 组件来构造界面这样通过界面对象的使用不但可以满足用户对界面的苛刻要求还可以让界面对象专注于用户交互和操作导航适应多变的业务需求而不是时时受到业务变化的影响 其次将业务逻辑从界面中剥离出来可以进一步细化和分解业务通过将业务分解成不同的业务对象可以提高对象间的内聚力降低耦合度这样一来分别针对不同业务对象进行的维护和管理可以避免牵一发而动全身的风险 最后从不断发展的眼光来看分离的界面和业务可以互不干扰地升迁到新的结构体系中适应新技术潮流最终实现分布式跨平台的应用 可以说界面和业务的分离是一个可扩展可重用系统设计的基础也是面向对象思想的集中体现 界面和业务的分离经由逻辑分离物理分离直至空间分离最终实现了分布式多层体系结构成为企业级应用的主流趋势通常分布式系统划分为3层即表现层业务层和数据层如图 8-1所示表现层用于和用户交互它提供用户界面及操作导航服务业务层用于业务处理提供商业逻辑等各种约束数据层用于数据的集成存储这些数据即可以是平面文件也可以是RDBMS 1管理的数据图 8-1体系结构通常划分为3层表现层有两种主要的用户界面选项Win32客户机和基于浏览器的客户机1 RDBMS 是关系型数据库管理系统Relational Database Management System是用来存储和管理数据库的引擎著名的RDBMS 有Oracle SQL Server 等刘艺作品试读 china-pub 350 Win32客户机是最容易创建的提供一个更丰富的用户界面它通常由可视化的开发工具如Delphi 创建不足之处是这种客户端软件很难安装和维护它需要在每台客户机上安装需要升级时必须对每台客户机进行更新除了为客户机安装软件以及维护更新时很麻烦外还有另一个很难解决的问题由于安装在客户机上的操作系统和其他软件的版本不同客户机上的DLL 冲突很频繁这些冲突很难诊断和解决被称为DLL Hell 基于浏览器的客户机较难创建它提供了一个比较有限的用户界面只包含几个控件而且对屏幕布局和屏幕事件处理的控制也很少但它们很容易安装所有客户机只需要一个兼容的浏览器和一个Internet 或Intranet 连接 基于浏览器的客户机可以使用一些技术如客户端脚本或者Java 小程序以及最新的Web Form 技术使用户界面更丰富功能更强这些方法都适用于当前大多数浏览器 一般情况下基于网页的解决方案用非常适用于基于web 浏览器的企业内部互联网和外部互联网应用程序它易于维护使用方便跨系统跨平台等诸多优势已经越来越受到人们的追捧成为一种很有竞争力的解决方案 业务层也叫事务逻辑层或中间层是应用程序的脉搏它负责在分布式系统的中间层处理数据那里有事务处理规则和业务流程约束数据的处理这一层主要用于大批量处理事务支持大型配置信息传送和网络通信由此可以看出这一中间层很复杂 在分布式系统中我们可以把复杂业务关系细分为多项功能单一的服务每项服务都执行一项特殊任务这些服务可以用相对独立的服务组件来实现其功能通过分布这些组件我们可以平衡数据处理负载协调业务逻辑关系调整业务规模和业务规则 这一切在技术上都是可以实现的例如COM+1负责基本的COM 和事务处理功能IIS负责Internet 服务如SMTP Simple Mail Transfer Protocol FTP File Transfer Protocol 和HTTP Hyper-Text Transfer Protocol 每项服务都可以享用其它服务和创建新服务 业务层是很重要的它包含了目前提供特殊服务的数目最大的组件对象这种灵活性是大型的企业应用程序所需要的它可以根据表现层的用户请求从数据层获取处理并返回数据以响应用户需求 许多开发者更喜欢把业务层分为三个子层从而创建了五层体系结构其中三个子层为• 外观服务层或应用程序服务层工作流层负责与表现层进行通信实现应用程序用户界面外观的服务• 主业务服务层包含各种业务对象服务对象完成业务逻辑• 数据库服务层这一层专门负责与数据库通信负责建立SQL 语句和调用存储过程实现对数据库的访问 把业务层分成外观服务层主业务服务层和数据库服务层的好处是外观层更接近用户应用程序而不是业务逻辑而主业务仅包含了实际的业务逻辑因此能够根据特定用户的应用程序来设计外观层从而在应用程序使用中按照需求的变化灵活改变外观层的类以便实现新的界面比如用户需要将传统的Windows 窗体界面更换到web 网页界面时我们可能需要修改的仅仅是外观层中对应类的接口而已因为主业务类实现的是抽象的业务逻辑而不是任何特定的应用程序功能所以它能设计出更好的重用性由于它不像外观层的类那样允许自由修改所以保持了健壮性同样数据库服务层把主业务从数据库的复杂逻辑中分离出来便于有效地使用COM 或MIDAS 来管理事务从而进一步将组件中事务部分从非事务部分分离出来同时数据库服务层专门负责与数据库通信负责建立SQL1 COM+COM+是COM 的扩充通过添加服务扩展了COM 使其可以用于企业中而COM 只提供了组件框架要使COM 组件有事务处理能力还需要附加的服务这是COM+的目的COM+现已在微软的Windows2000/XP 中使用其中Windows2000中使用的是COM+1.0版WindowsXP 使用的是COM+1.5版刘艺作品试读 china-pub 351 语句和调用存储过程实现对数据库的访问Delphi 中的远程数据模块实际上就起到了数据库服务层的功能 数据层实际上就是资源管理层与业务层相比没有或较少有数据的处理而是定义了大量数据的管理任务数据库和资源会变得越来越多因此这项任务也变得越来越困难通常数据层使用大型的RDBMS 来管理如Oracle 使用RDBMS 来管理数据的好处是可以协助数据的处理提高数据的使用效率Ian Graham 认为现有的结构化方法对于分布式系统不仅几乎没有什么贡献反而在实际上阻碍了它的发展对象技术提供了模型化分布式系统的一种自然方法面向对象方法原理与实践机械工业出版社2003年3月 在分布式系统中由于网络和中间件技术解决了通信上的问题网络节点可以看成是对象或对象集业务对象在网络上的分布是透明的客户端用户请求业务对象服务时不需要关心该对象的所在位置网络间的通信变成了对象间的通信这就是Ian Graham 认为的对象模型所提供的自然方法显然人们越来越重视分布式系统由于对象技术具有封装和消息传递的特点因此对象技术可能是最适合采用的方法Ian Graham 同上 然而从界面和业务分离到分布式多层体系结构并不是一蹴而就的关于这方面的讨论有太多的理论文章但对于程序员来说如何实现才是最关键的 在这一章我专门设计了一个界面和业务分离的演化实例通过开发实践来帮助读者体会界面和业务分离的重要性掌握Delphi 的常用实现方法最后通过业务跨平台和界面跨平台的解决方案和开发实例展示了分布式应用中的最新潮流以及Delphi 支持新技术方面的强大功能8.2 界面和业务分离的演化实例8.2.1一个典型的RAD 程序在许多数据库应用程序中我们都需要有一个数据记录的维护模块图 8-2就是一个典型的用户维护的数据库应用程序该程序提供一个模糊查询功能系统管理员可以查询到一个符合条件的用户集并能选择其中某个用户对其详细信息进行维护 显然很多Delphi 程序员都有设计这样一个数据库程序的经验按照RAD 的方法我们可以在Form 上拖放一些数据库控件如图 8-3所示并在一些响应事件中填写代码最后完成程序如示例程序 8-1所示对于熟练的程序员整个过程要不了半小时刘艺作品试读 china-pub352图 8-2用户维护一个数据记录的维护程序图 8-3 用户维护简单桌面程序的RAD 设计界面刘艺作品试读 china-pub353 示例程序 8-1用户维护一个简单桌面程序的源代码unit Unit1;interfaceuses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,Dialogs, DB, ADODB, ExtCtrls, DBCtrls, StdCtrls, Grids, DBGrids, Mask,Buttons;typeTForm1 = class(TForm)btnQryByName: TSpeedButton;Label1: TLabel;Label2: TLabel;Label3: TLabel;Label5: TLabel;Label6: TLabel;Label7: TLabel;btnExit: TButton;edtQryByName: TLabeledEdit;DBEdit1: TDBEdit;DBEdit2: TDBEdit;DBEdit3: TDBEdit;DBEdit4: TDBEdit;DBGrid1: TDBGrid;dbcbSex: TDBComboBox;dbcbDep: TDBComboBox;DataSource1: TDataSource;adqDep: TADOQuery;adqUser: TADOQuery;btnUpdate: TBitBtn;procedure FormCreate(Sender: TObject);procedure btnQryByNameClick(Sender: TObject);procedure btnExitClick(Sender: TObject);procedure btnUpdateClick(Sender: TObject);private{ Private declarations }public{ Public declarations }end;constADO_STRING='Provider=Microsoft.Jet.OLEDB.4.0;’刘艺作品试读 china-pub 354+’ Data Source=wz.mdb;Persist Security Info=False' ;varForm1: TForm1;implementation{$R *.dfm}procedure TForm1.FormCreate(Sender: TObject);vari: Integer;tmpstrs: TStrings;begintmpstrs:=TStringlist.Create;with adqDep dotryConnectionString:=ADO_STRING;sql.Clear;sql.add('select * from M_BMBM');Open;for i:=1 to RecordCount dobegin tmpstrs.Add(Fieldbyname('BMMC').AsString);Next;end;Close;finallyClose;end;dbcbDep.Items:=tmpstrs;end;procedure TForm1.btnQryByNameClick(Sender: TObject);beginwith adqUser dobeginclose;ConnectionString:=ADO_STRING;Parameters.ParamByName('name').value:='%'+edtQryByName.Text+'%';open;end;btnUpdate.Enabled:=true;end;刘艺作品试读 china-pub 355procedure TForm1.btnExitClick(Sender: TObject);beginclose;end;procedure TForm1.btnUpdateClick(Sender: TObject);beginadqUser.Post;end;end.这样的代码对于初学编程的新手作练习用还问题不大但是在很多专业的应用程序开发中出现这样的代码就很危险了因为这里将用户界面和业务逻辑混在一起如果出现问题需要维护业务代码的修改会同时牵动到界面代码显然这是没有经过设计的至少没有体现设计思想的随意写法虽然该程序可以实现既定的功能但这是写死的程序没有灵活性这种应用程序是一次性程序没有一点可重用的价值这里的例子还比较简单但如果界面和业务都很复杂这样的写法是致命的我就见过一位程序员在一个按钮的click 事件中写了上百行的业务逻辑代码这是何等的恐怖这样的程序无论是阅读还是修改都是不可想象的8.2.2 界面和业务的逻辑分离 o p e CreateT o createT T T o p DataModuleCreate(..)T o p btnExitClick(..)T UserDM objUsers刘艺作品试读 china-pub 356图 8-4界面和业务的逻辑分离的设计为了将示例程序 8-1设计成界面和业务的逻辑分离的应用程序我们首先要将程序中的逻辑划分成外观类和业务类对于数据库应用程序最好再划分一个和数据库访问类如图 8-4所示外观类通常是GUI 界面对象如Windows 窗体它可以通过RAD 的方式可视化地完成设计在这个程序中我使用了TfrmUsers 作为外观类其设计如图 8-5所示注意这里只提供交互界面不提供业务实现图 8-5 通过RAD 的方式可视化地完成外观类TfrmUsers 设计 业务类用于实现业务逻辑那里有事务处理规则和业务流程约束数据的计算在这个程序中我使用了TUserMaint 作为业务类并把这个类放在一个普通的Pascal单元文件中TUserMaint 是我自己设计的非可视化类无法像控件一样进行拖放图 8-6在数据模块中添加数据库存取组件 对于数据库应用程序数据库访问类可以集中完成数据集和数据库的连接这里我使用了TUserDM 类作为数据库访问类它是一个数据模块TDataModule 的派生类TUserDM刘艺作品试读 china-pub357 类是一个容器我们可以使用RAD 的方法可视化地在其中添加和设置数据库存取组件如图 8-6所示读者可以看出这里我使用的是ADO 数据库存取组件由于使用了数据库访问类一旦我们需要更换数据库如换成Oracle 或SQL Server 或数据库存取技术如换成DBE 或DBExpress 存取技术只要在这里做修改就行就不会影响整个程序因为我们没有直接访问数据集组件如TADOQuery 而是间接地通过TDataSetProvider 组件来访问数据集的至于TDataSetProvider 组件连接的是TADOQuery 还是TTable 对业务和界面部分都没有关系这里实际上涉及到一个灵活使用RAD 的问题虽然我们是采用完全面向对象的思想来编程但通过拖放组件提高了我们编程的效率不少自称高手的Delphi 程序员武断地认为只要使用数据库组件就无法实现面向对象的思维无法将业务和界面分离从而反对使用数据库组件我这个例子就是专门针对数据库设计的我们已经看到了在数据库访问类TUserDM 中我使了数据库访问组件和数据集组件其实细心的读者在外观类TfrmUsers 上也不难发现我使用了data-aware 控件最重要的是我还使用了TClientDataSet 组件由于Delphi 提供了DataSnap 技术使得TClientDataSet 组件和TDataSetProvider 组件互相结合完成数据封包传递和解析的过程所以可以将数据集和数据显示及处理分离开以便实现数据库应用上的逻辑分离由于使用了数据库相关的组件使得我省去了大量的繁琐编码读者可以看到最终的程序十分简洁 在完成了代码逻辑上的分离设计我们最好将这些逻辑分离的代码存放在不同的单元文件中如图 8-7所示这样既便于修改维护又可以进一步通过封装实现物理上空间上的分离图 8-7将逻辑分离的代码存放在不同的单元文件中 我们现在来看一下经过逻辑分离后的界面单元代码示例程序8-2这里的代码仅仅供用户界面交互使用没有更多的逻辑其中业务逻辑的功能是通过业务对象objUsers 来实现的它是TUserMaint 的一个实例这就是说以后需要维护和修改业务逻辑需要改动的是TUserMaint 而不是TfrmUsers 如果需要修改应用程序的外观也只需要改动TfrmUsers 而不是TUserMaint 这就是分离的好处它是通过类来抽象逻辑封装代码实现的示例程序 8-2中数据集的传递是通过TClientDataSet 组件cdsUserMaint 的数据封包实现的查询数据时cdsUserMaint 从objUsers 对象获得Data 包更新数据时 cdsUserMaint 将数据更新变化装在Delta 包中传出完成数据库更新刘艺作品试读 china-pub358示例程序 8-2 逻辑分离后的界面单元代码unit ufrmUsers;interface usesWindows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, DB, DBClient, StdCtrls, DBCtrls, Grids, DBGrids, Mask, ExtCtrls, Buttons,uUserMaint; typeTfrmUsers = class(TForm) btnExit: TButton;btnQryByName: TSpeedButton; Label1: TLabel; Label2: TLabel; Label3: TLabel; Label5: TLabel; Label6: TLabel; Label7: TLabel;edtQryByName: TLabeledEdit; DBEdit1: TDBEdit; DBEdit2: TDBEdit; DBEdit3: TDBEdit; DBEdit4: TDBEdit; DBGrid1: TDBGrid; dbcbSex: TDBComboBox; dbcbDep: TDBComboBox; DataSource1: TDataSource; cdsUserMaint: TClientDataSet; cdsUserMaintID: TWideStringField; cdsUserMaintNAME: TWideStringField; cdsUserMaintSEX: TWideStringField; cdsUserMaintJOB: TWideStringField; cdsUserMaintTEL: TWideStringField; cdsUserMaintCALL: TWideStringField; cdsUserMaintDEP: TWideStringField; cdsUserMaintGROUP_ID: TWideStringField; cdsUserMaintPASSWORD: TWideStringField; btnUpdate: TBitBtn;procedure btnUpdateClick(Sender: TObject); procedure btnQryByNameClick(Sender: TObject); procedure FormCreate(Sender: TObject); procedure btnExitClick(Sender: TObject);刘艺作品试读 china-pub359procedure FormDestroy(Sender: TObject); privateobjUsers:TUserMaint; public{ Public declarations } end; constM_TITLE='操作提示';//所有提示对话框的标题implementation{$R *.dfm}procedure TfrmUsers.btnUpdateClick(Sender: TObject); var nErr:integer; beginif cdsUserMaint.State=dsEdit then cdsUserMaint.Post; if (cdsUserMaint.ChangeCount > 0) then beginobjUsers.UpdateUserData(cdsUserMaint.Delta,nErr); if nErr>0 then application.MessageBox('更新失败',M_TITLE,MB_ICONWARNING)elsebeginapplication.MessageBox('更新成功',M_TITLE,MB_ICONINFORMATION) ; btnQryByNameClick(nil); end; end; end;procedure TfrmUsers.btnQryByNameClick(Sender: TObject); beginbtnUpdate.Enabled:=true;dbcbDep.Items.AddStrings(objUsers.GetDepList); cdsUserMaint.Active:=false;cdsUserMaint.Data:=objUsers.GetUserList(edtQryByName.Text); cdsUserMaint.Active:=True; end;procedure TfrmUsers.FormCreate(Sender: TObject); beginobjUsers:=TUserMaint.Create; end;刘艺作品试读 china-pub360procedure TfrmUsers.btnExitClick(Sender: TObject); begin close; end;procedure TfrmUsers.FormDestroy(Sender: TObject); beginobjUsers.Free; end; end.示例程序 8-3是逻辑分离后的业务单元代码这里完成查询和维护数据记录的业务需要说明的是我这里仅仅是一个简单的示例程序没有包括数据的合法性检查事务处理异常处理等许多重要逻辑在实际系统中业务会更复杂示例程序 8-3逻辑分离后的业务单元代码unit uUserMaint; interface uses Windows, Messages, SysUtils, Variants, Classes,DBClient,udmUser;typeTUserMaint = class (TObject) privateUserDM:TUserDM; publicfunction GetDepList: TStrings;function GetUserList(strName:String): OLEVariant;procedure UpdateUserData(UserData:OleVariant;out ErrCount: Integer); constructor create;destructor Destroy;override; end;implementation {********************************** TUserMaint }constructor TUserMaint.create; beginUserDM:=TUserDM.Create(nil);刘艺作品试读 china-pub361end;destructor TUserMaint.Destroy; beginfreeandnil(UserDM); inherited; end;function TUserMaint.GetDepList: TStrings; vari: Integer;tmpstrs: TStrings; begintmpstrs:=TStringlist.Create;with UserDM do tryif not adcUser.Connected then adcUser.Connected:=True; adqTemp.sql.Clear;adqTemp.sql.add('select * from M_BMBM'); adqTemp.Open; for i:=1 to adqTemp.RecordCount dobegintmpstrs.Add(adqTemp.Fieldbyname('BMMC').AsString); adqTemp.Next; end;adqTemp.Close; result:=tmpstrs; finallyadcUser.Connected:=False; end; end;function TUserMaint.GetUserList(strName:String): OLEVariant; beginwith UserDM do tryif not adcUser.Connected then adcUser.Connected:=True; with adqByName do begin close;Parameters.ParamByName('name').value:='%'+strName+'%';刘艺作品试读 china-pub362open;result:=dspUser.Data; end; finallyadcUser.Connected:=False; end; end;procedure TUserMaint.UpdateUserData(UserData:OleVariant;out ErrCount: Integer);beginUserDM.dspUser.ApplyUpdates(UserData,0,ErrCount); end; end.由于使用了数据库组件在数据模块单元udmUser 示例程序 8-4中几乎没有什么额外的代码唯一的代码是为了设置ADO连接字符串adcUser.ConnectionString:=ADO_STRING;虽然高版本的Windows 系统都带有ADO 驱动程序用户可以不必像BDE 或ODBC 那样进行数据库设置但数据源的位置还需要指定ADO 连接字符串ADO_STRING 中Data Source=wz.mdb 表示程序使用的Access 数据库wz.mdb 保存在和应用程序相同的目录下我没有在TADOConnection 组件中直接设置ConnectionString 而是将其放在一个字符串常量ADO_STRING 中是为了方便读者修改因为我不知道读者会把光盘中的示例程序复制到哪里示例程序 8-4 数据模块单元udmUserunit udmUser;interface usesSysUtils, Classes, DBClient, Provider, DB, ADODB; typeTUserDM = class(TDataModule) adcUser: TADOConnection; adqByName: TADOQuery; dspUser: TDataSetProvider; adqTemp: TADOQuery;procedure DataModuleCreate(Sender: TObject); private刘艺作品试读 china-pub363{ Private declarations } public{ Public declarations } end; constADO_STRING='Provider=Microsoft.Jet.OLEDB.4.0;Data ‘+’Source=wz.mdb;Persist Security Info=False' ;implementation{$R *.dfm}procedure TUserDM.DataModuleCreate(Sender: TObject); beginadcUser.ConnectionString:=ADO_STRING; end; end.现在如果我们运行经过修改后的这个程序发现和原先程序的功能没有什么两样有的读者可能会抱怨既然如此何必要把事情搞得那么复杂多出了很多代码和单元文件是的如果你打算写一个桌面小程序当然不用进行这样复杂的考虑如果你是要完成一个重要的商业软件产品或是一个大型的项目工程你就不得不养成一个这样考虑问题的习惯必须在设计时充分考虑逻辑上的分离与独立每一个环节避免界面和业务代码纠缠在一起的实现这如同建一个狗窝和建一幢高楼的区别对于前者你可以快速搭建不用设计大不了推翻重建但对于建高楼你却要小心谨慎因为你付不起这样的代价另外将分离出来的独立的逻辑划分到不同的单元文件中也是一个好习惯除了修改维护上的便利外还可以进一步进行物理上的封装轻松实现C/S 结构或多层结构8.2.3 界面和业务的物理分离我用ModelMaker 来进行界面和业务的物理分离的设计如所示我将界面部分设计成一个瘦客户机的形式这是一个供用户交互的可执行文件distributabel2.exe 它封装了外观类TfrmUsers 我把业务部分包括数据模块设计成提供服务的服务器这是一个动态链接库文件UserSvr.dll 它封装了业务类TuserMaint 和数据库访问类TuserDM刘艺作品试读 china-pub364o reateT T T o create T o pe DataModuleCreate(..)T o pe btnExitClick(..)T Tf rmUsersu TIUserMaintu TUserDMu TUserMaintu TIUserMaintu objUsersUserDM图 8-8界面和业务的物理分离的设计由于原来的逻辑独立的类和代码存放在不同的单元文件中我们很容易重新将它们划分到不同的项目里如图 8-9所示图 8-9重新将逻辑独立的单元文件划分到不同的项目里瘦客户机其实上就是一个空壳只提供交互的界面它的外观类TfrmUsers 向TUserMaint 的实例对象请求服务该对象封装在DLL 中前面我已经讲过如何用DLL 来封刘艺作品试读 china-pub365装对象除了前面讲过的两种方法外这里我想介绍第三种方法即使用抽象类做接口的方法由于调用DLL 的应用程序只能使用DLL 中对象的动态绑定的方法我们不妨专门设计一个抽象类TIUserMaint 作为提供对象方法的接口在抽象类TIUserMaint 中有供应用程序使用的对象方法不过它们都是虚抽象方法目的是支持动态绑定而又无需提供实现我将新增的TIUserMaint 放在抽象类接口单元uIUserMaint.pas 文件中其源代码如示例程序 8-5所示这个单元将作为接口文件分别包含在UserSvr 和Distributable2项目中如图 8-9所示示例程序 8-5抽象类接口单元uIUserMaint 代码unit uIUserMaint;interface uses Classes; typeTIUserMaint = class (TObject) publicfunction GetDepList: TStrings;virtual;abstract;function GetUserList(strName:String): OLEVariant;virtual;abstract;procedure UpdateUserData(UserData:OleVariant; out ErrCount: Integer); virtual;abstract;constructor create;virtual;abstract; end;TIUserMaintClass=class of TIUserMaint;implementation //没有实现代码 end.在示例程序 8-5中还定义了TIUserMaintClass 类型它是TIUserMaint 的类引用这对于把实现类从DLL 传递到进行调用的应用程序是必要的一般抽象类只定义接口它由虚抽象方法组成而没有实际的数据为了实现抽象类TIUserMaint 的抽象方法原来的TUserMaint 类需要继承TIUserMaint 类并覆盖其所有的虚抽象方法新的TUserMaint 类声明如下TUserMaint = class (TIUserMaint) privateUserDM:TUserDM; publicfunction GetDepList: TStrings;override;。