1基于混合模式的表现层框架构建要点
为了解决上述表现层中分析建模与设计建模遇到的问题，首先定义一个基于混合模式的表现层开发框架。策略是:(1)针对编制层面和编排层面的复合构件的差异，引入Presentation设计模式中的两种基本层定义出这两种复合构件在表现层中的行为和状态，并阐述其相互间的调用关系;(2)针对3种消息传递机制的共性和实现机理，引入Singleton和Ob-server的混合设计模式管理全局消息的事件进行绑定，并提出完整的事件派发与接收的范式，用以规避传统的冒泡事件机制所引发的定位失误问题;(3)针对业务逻辑处理模型在表现层中的定义和接口的模型规约，引入Module模式给出以业务逻辑处理模型为单元复用转换规则在表现层的模块化方案。这样本框架就以一种完整的方式构建了表现层平台下融合多种设计模式的开发框架。
1.1使用Presentation设计模式分离复合构件的表现模型
如2．2节所述，存在于表现层中的复合构件分为基于编制层面和基于编排层面两种类型。其中前者一般由美学设计师负责UI(原型接口)设计，这类复合构件会改变元模型的“瞬间态”，即仅改变元模型的表现方式。而后者由交互设计师和前端设计师协同设计，主要用来某种业务逻辑，它会与其他外部复合构件交互进而元模型的熵值变化，即“持久态”变化。框架引入Presentation设计模式，其目的是将基于编排层面的复合构件从表现层中抽离出来，使得表现层回归于纯粹的视图设计，进而实现构件对象的内部逻辑与外部业务的解耦合。Presentation模式不属于《设计模式》［9］中定义的23种通用设计模式之一。架构设计大师MartinFowl-er将其定义为:“用于表示完全独立于界面中使用的GUI控件的可视化界面(或称之为视图)的状态和行为的设计模式［10］”。简单说，Presentation模式中将视图层中不属于图形界面部分状态和行为抽离出来，把抽离出来的这部分叫做表现模型(PresentationMod-el，PM)。Presentation模式有两种不同的实现方式:一种是视图监控表现模型，通过用户操作界面元素改变模型的状态和行为，通常称之为“拉”模式;另一种是表现模型监视视图，通过模型变化改变元素的状态，称之为“推”模式。在前端应用中，用户通过操纵表现模型与系统进行交互。处于View层的基于编排层面的复合构件可由数个子构件组合而成，每一个View的表现模型均包含一个对应的基于编制层面的复合构件用以封装构件的数据和状态。由于PM只需专注于具体逻辑的实现，而不用考虑与其他构件的交互问题，因此可用“拉”模式设计架构，如图1所示。
1.2使用Singleton和Observer混合模式建立消息传递机制
在2．2节中将应用中所有构件与模块的互访问技术按照区域归纳为3种类型。浏览器的访问技术采用事件的捕获———冒泡传递机制。这种机制分为“向下捕获”和“向上传递”两个阶段［11］，其原理为:父级元素遍历其子(孙)元素并捕获其元素实例派发的事件来相互访问。由于表现层框架中的复合构建是耦合松散的，这意味一个复合构件中不会包含其他复合构建的实例，也就不能通过注册其实例的事件监听机制相互间传递消息。因此，需要在复合构建或模块之间建立一个约定的“通道”，用以实现消息的派发、传递和接收这个完整步骤。显而易见，这个用于连接相同的访问域内所有构件“通道”在其域内是唯一存在的。因而顺理成章地使用Singleton(单例)模式作为消息传递机制的桥梁。Singleton模式的意图是:保证一个类仅有一个实例，并且提供一个访问它的全局访问点［12］。通常情况下，每个类在整个作用域中只存在独一无二的实例。每个交互域(Scope)均有唯一的用Singleton实现的EventBus作为域内通讯总线，如图2所示。域内的构件监听EventBus绑定事件的方式用以传递消息，因而采用Observer模式［12］构建框架的事件监听机制。为了加强事件监听的效率，传递的事件需具备以下标准:(1)事件的名称(EventName)，用以定义事件的功效，其命名通常不与事件分发构件相关;(2)事件的状态值(EventType)，定义其携带数据的处理类型;(3)事件的传递范围(EventScope)，用于控制消息传递范围，通常至少有Local、Global和Cus-tom三种可选值。考虑到前端各个模块运行时的独立性和并发性，使用Singleton作为传递域内唯一的交互通道，既区别了构件间的交互范围，也因使用唯一的EventBus实例而无需反复构造和销毁消息传递通道，减少了系统的运行负担。另一方面，使用Observer模式发布和订阅处理在EventBus上传递的数据，使得一个事件分发后可由多个模块捕获，进而同步更新构建的状态。这样一来提供了框架构件之间的消息传递机制的解决方案。
1.3使用Module设计模式封装业务逻辑处理模型
系统的各个功能模块化，其目的是为了削弱各个功能间代码依赖关系，减少耦合，从而提高开发的效率。为此，应设计一个规范的框架，所有的功能都以子模块的方式按照一定的规则进行开发与设计。各个子模块之间彼此实现一个开放的通用接口用于彼此的交互以及接口方法之间的映射。同时，模块在主程序中的生命周期和内部实现则由项目的开发团队负责实现。系统功能模块化主要关注模块(Module)的定义，其基本属性如下:(1)模块名称:该功能模块名称。(2)模块描述:是对完成既定功能的任务描述，包含实现该功能所使用的组件、模型和调用的外部服务。(3)模块的交互接口:接口是各模块间数据与状态值的传递通道，用于约定传递参数和方法的格式和规范。框架采用请求-处理的异步交互技术，模块间所有的交互采用事件传递机制。与构件之间交互的不同之处在于:每个Module必须保持其各自的私有化状态，这表示封装后的模块无法访问其他Module的私有化属性。若要实现模块之间的相互调用，则需对模块进行接口设计。由于功能型模块只实现单个任务，且向所有绑定的用户角色提供相同的功能，因此其功能只需用独立的构件来实现。但对架构师而言，该功能可以包含任意复杂的逻辑业务。因此，定义由功能模块发出的任务为构件的组合，这个过程允许开发者对模块功能在构件的级别进行拆分和定义。也就是说，允许将模块的开发分割成多个子构件，并定义这些复合构件的状态以及构件之间的交互逻辑，再将未编码的构件以开发任务的形式进行规划。
2基于混合模式的表现层框架实例设计
针对各种设计模式在表现层中的设计方案，构建基于混合模式的框架架构图，如图3所示。基于混合模式的表现层框架Module的方式封装业务模块，每个模块可由一个或多个独立的复合构件组成，采用Presentation设计模式将构件的状态和行为从视图中抽离出来，分成View和PresentationModel这两种功能不同的层次关系。应用由Module中的View层构件编排和布局，它掌控了前端架构中构件的层次关系;负责View层内部编制的构件封装在PM中，其绑定的数据协同为View提供可视化接口与其他构件协同完成任务。从图3中以“拉”模式为主的Presentation架构中可以看出，View可以根据逻辑界面包含一个或多个View构件，而其内部的PM相互之间并不存在相互依赖的关系，PM中也不包含其对应的View的引用。因而对PM进行编码时无需关注其对应的View层的表现方式，从而实现构件内部编制与外部编排的解耦化。为使分离后的各个构件间相互通信，因而在其所属Module中构造Singleton模式封装的EventBus。当与模块内其他构件交互时，原构件按照既定标准构造事件，它携带了传递数据和状态码，以EventBus为传输总线。同时，在以Observer模式设计的交互机制中，目标构件通过监听并过滤总线上传输的事件，按照一定规则判断事件名称、类型和所属范围即可接收数据，进而在模块内实现完整的消息传递过程。在使用Module封装功能模块间、主应用与子Module的消息互传递可依附于由Singleton模式封装的GlobalEventBus为载体。模块之间的交互主要体现在不同模块服务接口和请求接口的映射(InterfaceMap)。每个模块的设计均要实现以下接口和函数:请求接口(RequestInterface)、处理接口(HandleInter-face)和回调函数(CallbackFunction)。请求接口需要规定一个包含目标模块的唯一标识符(UniqueI-dentifier)和不定项参数序列(Arguments)的事件类为参数的方法。模块互动时，源模块无需引用目标模块的实例，只需分发该事件给信息流的传递框架即可。此时信息流的传递框架遍历当前运行态的事件总线(EventBus)中注册的所有模块，在目标模块实例的处理接口中接收事件，并根据模块的具体需求，基于相同的模式和技术可选择地分发回调事件，用于原函数调用的反馈处理。当整个架构完成后，软件工程师可基于此架构开发出一个完整的表现层应用。实例设计的效果体现在前端开发中引入多个设计模式构建出表现层框架。通过设计模式的组合，提高了Web应用在表现层中建模的要素，并针对建模设计中的难点选择合适的设计模式，进而降低了表现层开发的工作量。
3结束语
本文提出一种前端开发中引入多种设计模式后构建的表现层框架。在不引入重量级开发框架的前提下，成功地将前端中可视化界面与构件编码分离，不但减少了应用开发的时间成本和维护成本，为项目的测试、部署、再开发提供了便利，尤其为采用通用型构件的多任务Web项目提供进一步的支持。由于该框架的低耦合性且实现技术不依赖于实现语言，因而对其他客户端技术的表现层架构实现具有参考意义。
作者：雷明 单位：河海大学商学院
