快速创建可复用体系结构


  快速创建可复用体系结构
快速创建可复用体系结构



内容摘要


学习如何使用模式和IBM Rational XDE 2003来创建你自己的可复用框架。


显著节约成本的重用一直是软件工程的“圣杯”。从复制和粘贴源代码到类层次上的细粒度(fine-grained)复用,再到框架和体系结构层次上的粗粒度(coarse-grained)大规模复用,复用技术已经逐渐成熟。而在体系结构上的显著节约成本的重用应该成为所有开发项目都致力的一个战略性活动。在读过这篇文章后,你将会明白运用模式及IBM Rational XDE V2003 如何创建你自己的可复用框架。

  注释: 所有的模型和代码都使用XDE v2003 for .NET来描述。类似的的框架可以在J2EE环境下建立。代码语言采用C#,所以对于C++或JAVA程序员都应该是清晰易懂的。


复用体系结构


  大约二十多年前,软件工程业被比喻成旧时代的打铁。在那个时候,当你想建一座房屋,要去铁匠铺找所有需要使用的金属部件,从固定在墙上的烛台到锁门的铰链,甚至小小的钉子,都需要一个一个地手工来制造。这正如当时的软件工程--几乎所有的代码都是新的,每项规则和每个设计都是专门为正在构建的系统而编写,而且以后它们可能又需要重新被构建。代码复用(当时唯一可尝试的复用方式)可以被看成是在五金商店购买成百上千钉子,而不是自己亲手打造每一个钉子。这样,使用更为可靠的代码就可以缩短开发周期。

  在20世纪80年代中期,经济可行的面向对象编程语言的引入,诸如C++ (Smalltalk已出现,但并没有在业务环境中得到广泛使用),通过类直接支持代码的复用。复用方面已取得了一些重要的成果,但是预测中的“大跃进” 并没有如期而至。这是由于开发者常常不能决定哪些类应当被复用。的确,一些代码的复用,使将来的代码编写更为快捷、可靠。但是,直到可视化建模和代码生成工具的出现,开发者才开始看到设计复用—概念及思想--带来了比代码复用更大的经济回报。他们意识到在体系结构及设计层次上的复用将带来相当巨大的收益。


现在打铁匠的类比法更具有说服力。随着设计模式的发明,而且从设计模型中产生代码非常简单,所以复用设计便成为一种理念。现在,一改过去复用“钉子”的作法,我们正在复用基础和墙壁,这类似于预先建造房屋的组成部分。我们不再是房子的建筑者,而是房子的设计者。不再需要请众多邻居帮忙钉木板建房,你现在可以直接买墙壁和屋顶,然后在几个小时之内就能够完成装配。

  体系结构框架也是如此,为什么不从已有体系结构的20%,或者 30%,甚至60%来开始呢?为什么不在应用中使用相同的构架,以便更易于软件工程师在工作中连续的应用?微软建立MFC类库,Sun提出Java和 J2EE标准,他们都在作这方面的努力,而且,Microsoft目前又在尝试使用.NET来实现这种思想。正如他们90年代所作,更简单快捷、代价更低,并且更可靠地基于J2EE来构建Web应用。换而言之,像J2EE这样的框架为构建Web应用提供了经济显著的复用。

  "优质、快速、低成本:只能同时选择其中两个"是一个旧的工程定律,其中的一个必须为另外两个而作出牺牲。但是复用体系结构框架是降低风险的一种途径,并且同时兼顾了这三个原则。



快速体系结构


  大规模的工业体系结构,比如J2EE,已积累了大量的经验与资源,它影响着项目、公司和工业之间的可复用性。在创建体系结构上投入大量的努力,仍然能带来显著的投资回报(ROI)。但是如果我们不使用J2EE, .NET,或者一些其它的行业体系框架会怎样呢?或者要是我们的组织需要一个建立在J2EE或.NET之上的可复用体系结构,那又会怎样呢?我们可能只复用这个体系结构几次,或者几十次,而不是数千次,我们需要的是建立健壮的、可利用的架构能力。但是,快速却不够熟练的构建架构会给我们带来对于我们付出最小化的回报。


本文中,我们将使用设计模式快速建立框架,这是一个模式的模式。在XDE中应用这些模式将会产生大量代码。所以,实现这个框架的大多数代码不需要人工介入。即使这是使用模式所带来的唯一好处,我们仍然会有很多可用的代码。几行手写“粘合代码”将起到一个连接的作用。最后,我们将有一个3-tier 体系结构,它在可重复、可预测和健壮(基于组件)的框架中处理业务逻辑。这个框架可以复用(以单一模式应用,而不是重复敲入代码)来更快地建立其它应用架构。曾经从事这个框架的开发者在以后使用相同框架的应用时,不必再走弯路。框架的改进或加固会被快速地在应用间传播,这只需要通过重复应用模式即可,而不必多次手工修改代码。



处理业务逻辑


  我们将要建立的是一个简单的3-tier框架,它使用了三种模式处理业务逻辑:3-layer 体系结构模式、 Singleton模式和Command模式。Singleton和Command模式来源于Gang of Four所编著的“设计模式”,使用XDE来实现。本文中使用到的Command模式为达到清楚明了,已作了一定的简化。

  首先,我们来看看框架的行为。图1是一个时序图,描述框架将如何处理业务逻辑。


图 1: Business Logic Behavior


  业务对象以红色标注,用户接口对象是蓝色。当用户请求命令(应用功能)时,序列通过与用户接口对象相互作用来被执行。窗口是展示层的一部分,所以它不执行任何业务逻辑,但是它知道将请求传送到业务层。该窗口通过其业务逻辑层的接口来做这项工作,该接口是由BusinessLayerProxy类来实现的。这是一个控制器类,其职责是管理业务逻辑的执行。


BusinessLayerProxy建立或者访问CommandFactory实例,CommandFactory是一个Singleton,保证一个类在应用中仅有一个实例(对象)。使用Singleton模式,我们可以保证无论BusinessLayerProxy多少次尝试建立 CommandFactory,也只存在一个实例。CommandFactory知道它是否已有一个实例,如果存在,则不建立另外的实例。

  BusinessLayerProxy然后要求CommandFactory建立请求的业务逻辑对象(命令),这样,业务就可以被执行。这就是 CommandFactory唯一的工作--知道如何建立适当的业务逻辑。在我们的示例中,整型ID被传送到CommandFactory,于是,建立正确的Command对象。本文中这个简单的策略很容易理解。在现实生活中,我们可能需要更健壮(和复杂)的方法来识别建立哪些业务逻辑。使用其它模式(比如Abstract Factory 或Factory Method)能够减少维护开支,同时增加可用性。

  所有的业务逻辑通过应用 Command模式来封装在Command对象中。CommandFactory建立请求的业务逻辑的实例,并且将命令的接口传递给 BusinessLayerProxy。BusinessLayerProxy并不清楚执行什么命令,它只是通过ICommand接口执行一些业务逻辑(注意CommandFactory的返回值)。一旦BusinessLayerProxy有了接口,便通过execute()操作来执行命令。这是 Command模式的一个应用。

  在这个例子中,使用了一些不错的OO设计,每个类应当只做一件事,并且把它做好。所以 BusinessLayerProxy管理执行流,CommandFactory知道如何建立命令,每个command类封装--或是唯一的入口--用于单个应用服务的逻辑。只有经过业务接口,将表现层同业务层的变化隔离出来,业务层才是可访问的。封装、模块化和多态的应用均由模式来实现。XDE模式扩充的能力使得我们可以自由地应用这些好的设计。



框架


  我们从一个项目结构来开始(如图2所示)。这个结构是3-layer模式的应用,它把应用逻辑分成 Presentation、Business和Integration/Persistence这几个类别。某个层的代码能且只能通过接口访问该层(如图 3所示)。在本文中,我们主要关注业务层和显示层。在业务层,我们已有BusinessLayerProxy,它实现了IBusinessLayer接口并充当了整个业务层的管理者或控制器(如图4所示)。



图 2: Initial Project Structure



  所示3-layer模式就是它在被应用前的情形。Javascript被用做参数名的占位符。当应用这个模式时,Javascript将被实际的包/子系统名所代替,例如用“BusinessLayer”代替文本“<%=bizlayer%>”。


图 3: 3-layer Pattern


  应用的主窗体,“Form1”位于表现层,它必须通过其接口访问业务层(如图4)。在FORM1中有3个消息操作(..._Click()),都将使用关联“theBusinessLayer”来访问业务逻辑。



图 4: Main Form Accessing Business Logic


  代码与模型同步之后,我们能通过“theBusinessLayer” 访问业务逻辑。我门需要在消息处理中为FORM1写一行“粘合代码”,请求业务层执行适当的逻辑。ID“1”被传送到业务层,这样,就能够识别适当的业务逻辑。


private void Boltz_Click(object sender, System.EventArgs e)
  {
    theBusinessLayer.execute(1);
  }

  既然我们已经访问了业务层,就需要建立CommandFactory类。我们通过应用Singleton模式,创造一个新类CommandFactory。Singleton模式如图5所示。


图 5: Singleton Pattern


  当我们应用这一模式时,“Singleton”被 “CommandFactory”所取代。“Client”变成“BusinessLayerProxy”。GetUniqueInstance()是个静态方法,返回CommandFactory的实例。内部地,如果一个CommandFactory的实例不存在,则将会在创建一个。否则,将返回已存在的CommandFactory的实例。获取CommandFactory唯一的方法是通过GetUniqueInstance()操作。(注:Singleton的构造函数是私有的)。

  现在BusinessLayerProxy已访问CommandFactory。我们需要通过命令模式识别业务逻辑的位置,当BusinessLayerProxy发出请求时,在CommandFactory中就会创建command,最终执行该逻辑。

  图6显示的是命令模式的一个简化版本。所有的具体指令--所有的业务逻辑--实现命令接口。业务逻辑在execute()操作中实现。在现实的应用中,execute()可能利用类的协同来执行必要的业务逻辑。Invoker通过接口执行命令,而且Client创建命令,将参数传递给 Invoker。对我们的目的来说,

Command接口就是现有的ICommand接口(如图2所示)。Invoker总是 BusinessLayerProxy,创建者就是CommandFactory。应用的模式如图7所示。


图 6: Simplified Command Pattern 



图 7: Applied Command Pattern


  每个命令(业务逻辑)通过使用Command模式来添加,每应用一个Command模式,便会创建一个新的ConcreteCommand(如:FirstCommand类),其它3个类总是复用的。这就提供了一种可预测的方法来添加,修改和调整业务逻辑。


  我们写了一些“粘合代码”来连接CommandFactory和BusinessLayerProxy,这项工作只需做一次即可。我们也写了几行代码,以便从CommandFactory访问FirstCommand。本例中,我们使用的是简化的体系结构,所以每增加一个新的命令就需要操作一次。


  我们在Form1中添加一些代码来访问业务层,以下便是BusinessLayerProxy中的代码,来请求和执行业务逻辑:


public void execute(int ID)
  {
    GetCommandFactory();
    theCommandFactory.getCommand(ID).execute();
  }

  GetComandFactory() 保证了CommandFactory被初始化。getCommand(ID) 引起 CommandFactory 创建command对象(请看下列代码), 而且 execute() 是ICommand的操作,执行业务逻辑。

  以下是我们在CommandFactory中编写,来调用适当的业务逻辑:


ICommand theICommand;

public ICommand getCommand(int CommandID)
  {
    theICommand = null;
    switch (CommandID)
    {
      1: theICommand = new FirstCommand();
      break;
      2: // put the next command here
      break;
    }
    return theICommand;
  }


  最后要做的是事情是:在FirstCommand的execute()操作中编写出业务逻辑。瞧!可不是!业务逻辑被合理地封装,业务层有一种简单且可复用的方法来处理业务逻辑,框架现在也已定义,可以用于创建其它的应用系统。再次应用整个框架时,速度将远远快于第一次。


模式的模式可以被创建,所以框架能被输送并复用于其它任何地方(如图8所示)。在XDE中,可以创建这个模式的模式并将它作为可复用资产规范(RAS)导出。其它项目可以将框架导入,并能够以单一的模式或者单独地应用其中一些模式来复用该框架。



图 8: Business Logic Framework (pattern of patterns)


  改进

  “Undo”特性能被相对容易地添加到这个框架中,undo()操作可以被添加到ICommand,并且在每个ConcreteCommand中实现。不是在业务逻辑已经运行后删除命令对象,BusinessLayerProxy能把命令对象放在undo队列中,当用户调用undo,在行列顶端的 Command对象会被实现,并且它的undo() 操作被调用。使用相同的业务逻辑将这种Undo逻辑封装起来,原始地传递数据。

  日志能力可以很容易地增加到这个框架中。被称为“代码模板”的几段参数代码可以被添加,或者在XDE右击鼠标来实现。在模式中,当代码和模式同步时,把代码模板绑定到一个操作,便会生成相应代码。在Command模式中,将信息记录到文件中的代码能够被添加到ConcreteCommand的 execute()操作。

每个从command模式中建立的command类都会把信息写进日志,包括command类的名字或者模式中的任何参数信息。当代码模板已被绑定到execute()操作后,只击点击几次鼠标,再次应用command模式,便可以将功能添加到已存在的command类中。

  框架甚至可以被创建,作为J2EE, .Net,或者其它的行业体系结构框架的抽象层。开发人员将创建使用这种框架的应用系统,以设计者和实施者都相当明晰的方式,依次建立适用于潜在体系结构的类。最后这个例子对于企业从多个供应商在体系结构上运行应用非常有用,但它必须被认真地对待。

  总结

  体系结构和设计的复用在编码、维护、培训和易于理解这几个方面均带来了显著的功效。使用已在产品应用中经过验证的框架可以缩短开发时间,降低成本,并且提高产品质量。在本文中,我们经过运用3-layer, Singleton, 和Command模式来处理业务逻辑创建框架,该框架可以在不同情况下复用。只需书写少量的代码来支持这个框架,使得它易于从一个应用程序移植到另外的一个中,并且从一开始就提高代码的质量。总之,可复用框架为开发组织提供了一个相当的竞争优势。

来源:IBM    作者:Jim Ruehlin    责编:C/S框架网




C/S框架网|原创精神.创造价值.打造精品

扫一扫加微信
C/S框架网作者微信 C/S框架网|原创作品.质量保障.竭诚为您服务

版权声明:本文为开发框架文库发布内容,转载请附上原文出处连接
C/S框架网
上一篇:实例讲解基于事件的银行营销系统架构
下一篇:ADO-Direct模式部署到客户机器需要安装ASP.NET吗?
评论列表

发表评论

评论内容
昵称:
关联文章

快速创建复用体系结构
面向服务的体系结构(Service-Oriented Architecture,SOA)
什么是WCF以及WCF体系结构?|C/S框架网
GoF设计模式:享元模式(Flyweight Pattern)—实现对象的复用
什么是Web Api? ASP.NET Web Api体系架构
[原创] Asp.Net三层体系结构应用实例(2)源代码
TMS体系架构图 - 物流运输管理系统
Asp.Net三层体系结构应用实例(附C#源代码)
CSFramework.Workflow - 视化工作流引擎 - 数据库表结构
C/S结构快速开发框架使用的DevExpress常用组件
CSFramework.WebApi后端框架Token令牌体系架构与应用详解
C/S结构快速开发平台三层逻辑架构 (3-Tier Logic Architecture)
体系架构图
C/S系统快速开发框架旗舰版V5.0《数据库表结构说明书》
GoF设计模式:建造者模式(Builder Pattern)—复杂对象的组装与创建
软件开发与设计 - MIS-管理信息系统(力软快速开发平台数据库结构文档)
GitBlit 创建版本库,VS创建本地存储库并推送源码到远程版本库
ASP.NET MVC快速入门(一)
原创:C/S架构快速开发框架通用配置的数据修改日志解决方案
主窗体体系架构 / 逻辑架构 - MiniFramework蝇量框架 - Winform框架

热门标签
.NET5 .NET6 .NET7 APP Auth-软件授权注册系统 Axios B/S B/S开发框架 Bug Bug记录 C#加密解密 C#源码 C/S CHATGPT CMS系统 CodeGenerator CSFramework.DB CSFramework.EF CSFrameworkV1学习版 CSFrameworkV2标准版 CSFrameworkV3高级版 CSFrameworkV4企业版 CSFrameworkV5旗舰版 CSFrameworkV6.0 DAL数据访问层 Database datalock DbFramework Demo教学 Demo下载 DevExpress教程 DOM EF框架 Element-UI EntityFramework ERP ES6 Excel FastReport GIT HR IDatabase IIS JavaScript LINQ MES MiniFramework MIS NavBarControl Node.JS NPM OMS ORM PaaS POS Promise API Redis SAP SEO SQL SQLConnector TMS系统 Token令牌 VS2022 VSCode VUE WCF WebApi WebApi NETCore WebApi框架 WEB开发框架 Windows服务 Winform 开发框架 Winform 开发平台 WinFramework Workflow工作流 Workflow流程引擎 版本区别 报表 踩坑日记 操作手册 代码生成器 迭代开发记录 基础资料窗体 架构设计 角色权限 开发sce 开发技巧 开发教程 开发框架 开发平台 开发指南 客户案例 快速搭站系统 快速开发平台 秘钥 密钥 权限设计 软件报价 软件测试报告 软件简介 软件开发框架 软件开发平台 软件开发文档 软件体系架构 软件下载 软著证书 三层架构 设计模式 生成代码 实用小技巧 收钱音箱 数据锁 数据同步 微信小程序 未解决问题 文档下载 喜鹊ERP 喜鹊软件 系统对接 详细设计说明书 行政区域数据库 需求分析 疑难杂症 蝇量级框架 蝇量框架 用户管理 用户开发手册 用户控件 在线支付 纸箱ERP 智能语音收款机 自定义窗体 自定义组件 自动升级程序