基于RIA架构的应用开发改进方案

基于 RIA 架构的应用开发改进方案

周林 谢峰    

( 上海电力学院计算机科学与工程系 上海 200090

上海交通大学软件学院 上海 200030)

 

摘要：基于互联网技术的软件开发模式已经逐步成为大型应用软件开发的首选，但传统的B/S软件开发结构已逐步显现出自身的缺陷，RIA架构的推出无疑为B/S应用开发注入了活力。如何发挥RIA架构的优势，同时又保持传统结构的稳固性、简便性，并在此基础上建立适合应用开发的新型开发架构是本文讨论的重点内容。

关键词： RAP 模型  RIA 架构  J2EE MVC 架构

中图分类号：TP319    文献标识码：A

An Improvement Method for RIA Based Application Developping

Zhoulin, Xiefeng

(Shanghai Institue of Electric Power, Dept. of Computer Science & Engineering, 200090

School of Software, Shanghai Jiao Tong University, 200030)

Abstract     Web-based software developing architecture has been the prior method for building a eterprise application, but the common B/S approch has shown its limitation while an application goes more complex. The emergence of RIA architecture gives web-based system developers more confidence. A new architecture is put forward here to show how to combine the benefit of RIA-based platform and rapid application development.

Keywords  RAP Module  RIA J2EE MVC 

1.  分布式开发结构模型

随着互联网技术的发展，自从B/S架构迅速流行开来之后，基于这种结构的应用开发曾大行其道，但如何做到当初C/S结构那样的表示层精确控制以及良好的用户交互是我们一直挥之不去的难题。随后出现的RIA （Rich Internet Applications）架构使开发人员有机会满足更复杂的用户程序界面的功能性需求，创建更实用的应用程序。这些应用程序结合了桌面应用程序的反应快、交互性强的优点，以及 Web 应用程序的传播范围广及容易传播的特性。

RIA架构中的“丰富”，通常包含丰富的数据模型和丰富的用户界面两方面含义。丰富的数据意味着客户端的用户界面能表现和应对更多更复杂的数据模式，而丰富的用户界面使我们的运作模式变为只对发出请求的特定区域进行改变。这些结构的层次大都包括表现层、业务逻辑层和数据持久层，我们可以简单概括为下图所示的层次模型：

  图 1 常用分布式开发结构示意图

图中前端GUI结构中的视图（View）负责具体界面表现，而数据模型（Model）是视图上控件所对应的具体业务逻辑数据的集合。数据模型通过Control方法将视图的具体控件和数据模型做绑定，视图中每一个控件都对应数据模型中的一个具体属性字段。控制逻辑（Controller）主要处理前台的业务逻辑和一些表现逻辑，同时它还是一个状态机是事件的入口，分发具体的事件、进行页面跳转，或者与中间层交互。

2.  应用软件开发的新问题

但以上架构在具备这些优点的同时，也不能看出这个架构过于复杂，过于注重开发过程。比如要做一个界面就必须要实现三个类：Model、View和Controller，即首先要有数据逻辑对象，然后再根据数据逻辑对象字段添加相应的控件，然后再向Controller里面粘合Model和View。事件通常是通过消息方式进入Controller的，那么我们就要为每一个事件定义一个消息标识，同时要在Controller里用代理方法去实现此事件逻辑。而大多数企业级应用来说，所有的操作都基于数据库，就是对数据库的增、删、查、改。这些基本的数据库操作对于开发人员来说不是技术活，而是体力活。但从这个架构来看，并没有很好的解决这个问题，开发人员还是要实现这一系列的操作，重复的实现这些基本的功能。

显然，传统的分布式开发模型虽然功能强，扩展性好，但是却带来了开发成本以及开发复杂性过高的问题，从软件开发的角度来看，仍属于重量级过程，这些问题可以概括为：

用户需求难以把握——因为软件用户和软件开发商所处于不同的领域，所以用户对于软件的需求，软件开发需要经过反复的迭代调研才能慢慢了解和把握，但还是不能保证最终成型的软件和用户的需求没有出入。

用户界面开发成本高——虽然从软件开发的角度看，做界面没有什么技术含量，但是对于用户来说，界面是他们最终的业务表现形式，也是业务操作的唯一入口，所以界面对他们来说非常重要。

需求变化代价巨大——需求变更对于用户来说是再正常不过的事情，但是需求变更往往对软件本身来说是十分痛苦的事情，可以说伤筋动骨；而且软件改动后也很难保证和用户提出的需求没有出入。反复的返工不仅会打击开发人员的开发激情，也会延长整个开发周期。

开发过程中代码质量难以控制——在控制代码质量方面，虽然已经有了很多的技术，都可以生成代码模扳，但大都采取硬控制，即最多生成一个个模扳，而开发人员在这些模板的实现上，也许还会有体现出个人风格的代码。

3 、开发模型的改进

其实引起前述问题的主要原因，还是由于传统的分布开发过程过于复杂所导致，因此我们根据自身在开发过程中的经验，提出以下一些初步的改进设想：

首先，新的开发结构也应该能像传统方式那样，提供所见即所得的界面、简洁的拖拽布局方法，便于快速建立一个原型开发平台，第一时间掌握用户需求，并快速反映到用户界面上。其次，新的软件设计框架应该允许用户自己调整界面，从而将开发人员彻底从界面开发的繁重劳动中解脱，而把力量集中在业务模型的开发设计上。第三，在代码质量控制方面，应该提供足够的模板引擎机制，而不是传统的代码生成器，将传统模型中大量的非功能需求放入新的框架中，使开发量降到最低。

我们把改进后的架构称之为 RAP——Rapid Application Platform快速应用平台，鉴于RIA架构相比B/S架构而言，具有明显的稳定性更高、可操作性更强、性能更优等特点，因此我们这里提出的RAP模型是基于RIA架构的改进模型。

下图是改进后的模型结构图：

图 2 RAP 模型示意图

对比前面的分布式模型和上图所示的RAP模型，我们可以看出二者没有本质区别，因为我们的RAP架构就是建立在前者基础之上的，这样设计的主要目的是从保持原模型中良好的可维护性、可扩展性以及健壮性等几大优势。以下我们重点说明对原模型中相关问题的改进设计考虑，主要表现在以下几个方面：

3.1 MDI 与MVC 的结合

RAP模型中的前端GUI结构，从整体方面看是借鉴了传统C/S开发模型中的MDI风格，传统C/S开发模型中所见即所得的界面开发手段，是我们选择MDI风格作为GUI结构框架的因素之一；而对应到每一个具体业务操作的界面控制，则采用MVC模式。这是由于MVC 设计模式很清楚的划定了程序员与设计者的角色界限，换句话说，是从业务逻辑上拆解了数据，能够让设计者集中于设计应用程序的显示部分，而开发者则集中于开发驱动应用程序功能所需的组件，MVC 模式使代码易懂而且使代码更容易重用。

在RAP模型中，为以示和一般MVC的区别，我们将程序控制逻辑（Controller）称为模块控制逻辑（ModuleController），每一个模块控制逻辑都可以看成是一个具体业务界面操作的入口，而这个具体的业务界面就是一个模块（Module），它都有一系列的相关信息并保存于数据库中。进入模块则通过菜单和向导栏两种途径，挂在MDI框架上的每一个菜单，都会通过一个标识来表明它是对应那一个模块。由菜单或向导栏发送过来的事件消息，均由核心的MDI控制逻辑（MDIController）来处理，而无法直接处理的消息，则可以调用当前模块控制逻辑进行处理。

3.2  灵活的布局

我们曾讨论过用户界面开发是一项成本很高的工作，不仅很烦琐但又是用户非常关心的问题。在RAP模型中，我们针对这一点提出了一个全新的思想，即将整个的布局信息完全放在了配置文件中，也就是GUI引擎原理图中的view.xml。

从图3中我们可以看出，GUI引擎的主要原理就是解析用户的界面布局配置文件view.xml，并且生成相应页面实例。对view.xml的解析主要是基于其中的重要配置信息，这样我们可以通过工具或者其他方式动态地对界面进行一些设定，这有些像传统web页面的html或jsp形式，不过我们这里的页面配置文件不仅仅是简单的布局配置信息。

RAP模型的控件全都采用称为Icomponent的控件接口，为了适配控件接口需要对控件进行一些轻量级封装，同时对一些公用的属性设置也进行封装，比如在SNormalTextBox控件中可以设置MaxLength、LowerCase等属性，该控件就会自动的设置它在文本页面里的相应属性。

图 3 GUI 解析与控件装载示意图

RAP模型的一个核心思想就是为数据库中每一个字段都提供一个相应的控件实体（ComponentEntity），控件库可以放在数据库中也可以放在XML中。因为当今的大多数软件都是针对数据库操作的软件，而大部分的业务也是基于数据库中业务的字段，所以业务数据的页面表现到了RAP里面就是以它对应的实体出现，我们可以在XML文件中表示如下：

<component ce=”**.**” constraints=”…”…/>

这样做的好处是：第一，页面中的控件表示能够不限于具体的控件，可以完全基于控件库的配置，用户可以根据自己的需要来设定控件配置；第二，十分简便的重用控件和方便的控件更改。比如数据库中的一个字段长度由原来的50改成100，在RAP模型的控件库中更改一次该字段对应的实体配置就行了，而在传统设计模型中可能会非常痛苦：如果这个字段在系统中用了100次，那么就必须改100次。第三，所有的控件都是可重用的。通过可重用的控件，我们可以方便的进行一些控件级的验证，最为明显的就是长度校验。

3.3  动态数据绑定

数据绑定主要就是实现控件和数据对象的数据关联。在RAP模型中主要是采取在控件与数据之间建立监听来进行数据绑定。不过RAP的数据绑定和先前的传统软件设计中的不同之处在于：首先，RAP中数据绑定是以控件本身为最小元素，与数据对象中的相应字段建立监听连接。第二，RAP的数据对象与传统软件设计模型的完全不一样，RAP中称为Bean代理（BeanProxy），其实它的核心就是一个Hash表，这样整个模型就是一个动态的数据对象，随时可以向其中注入数值。

这样做的优势在于一方面能摆脱性能非常差的反射机制（Hash表的效率非常的高），另一方面可以在修改一条数据同时方便的做数据镜像（也就是保留原始数据），当修改结束的时候只提交修改的数据，最小化的优化了数据的流量。

从前面的叙述不难看出，整个前台架构的核心思想就是实现动态的数据显示方式——动态的数据绑定、动态的界面调整。但由于模型建立在一个动态Hash表上，所以要做到优雅的面向对象的设计是很困难的，在RAP中采用挂接业务逻辑对象的方法，也就是给BeanProxy套上一个包含有业务逻辑的数据对象，数据逻辑对象还是按照反射方法进行数据绑定。这样一来不仅保留了数据的动态性，同时也可以充分的利用继承、重用业务逻辑组件；这对于老式系统的改进也是一个非常有利的机制。

4.  结论

以上我们只是对RAP模型中的前端结构做了重点介绍，从中可以看出，RAP结构将快速开发与灵活易扩展的分布式架构有效的合二为一，模型中的整个前台架构不仅有着非常好的动态数据绑定性，而且有非常好的业务可扩展性。动态界面可以方便用户建立系统原型，而且在需求变更时，界面的开发代价降到最小。独立的业务逻辑组件功能，不但保证了系统具有良好的可扩展性，而且也为方便的搭建测试环境提供了基础。

本文作者创新点：通过将传统RAD软件开发方式与Web分布式开发相结合，建立快速应用开发平台，使得软件开发就如同搭积木一样简单；而该模型所具备的运行中动态界面、动态数据绑定等特性，不仅用户能方便的建立系统原型、简化设计流程，而且能够实现用户自行调整界面设计，使开发人员从繁重的重复劳动中解脱出来。此外，基于控件库的概念、丰富的框架模板不仅能节省大量的开发时间，也为保证代码开发质量提供了有效手段。

 

参考文献

[1] Grady Booch, Martin Fowler “Core J2EE Patterns: Best Practices and Design Strategies, 2nd Edition,”Prentice Hall PTR, June 10, 2003

[2] Rod Johnson, “Expert-One-on-One-J2EE Development without EJB,” Wiley,2004

[3] The O'Reilly Java Authors, “Java Enterprise Best Practices,” O'Reilly, December 2002

[4] 谢运佳等，一种轻量级的 J2EE 解决方案及其应用，微计算机信息 (2006)03-3 ，页码 P223-225

作者简介

周林，1968年生，男，讲师，任职上海电力学院计算机科学与工程系，研究方向：网络应用开发

地址：上海市平凉路2103号，邮编：200090 邮件：z046@133sh.com

Zhoulin ， 1968, Male, Instructor ,Shanghai Institue of Electric Power, Dept. of Computer Science & Engineering ， Study direction: Network Application Development

谢峰，1980年生，男，工程硕士研究生,上海交通大学软件学院，研究方向：J2EE企业应用开发体系架构      单位地址：上海市华山路1954号，邮编：200030

Xiefeng ， 1980, Male, Graduate of Engineering, School of Software, Shanghai Jiao Tong University ， Study direction: J2EE Application Architecture