摘  要  文章先介绍了Java^TM EE家族中的重要成员——JavaServer^TM Faces这一技术。它位于Java^TM EE的Web层面，为Web程序员提供了基于组件和事件驱动的编程方式，这将改变传统的Web程序编写方式。然后，本文分析了大型设备采购系统的固有特性，并介绍了如何结合JSF技术和DAO模式开发大型设备的采购系统。     关键词  JavaServer^TM Faces；JSF；大型设备采购；信息系统 

1  前言

    信息技术、机技术、数据库技术和软件工程技术的高速，使得计算机信息系统得到了长足的进步。高速网络和大型关系数据库的成熟，为构建计算机信息系统提供了良好的基石；软件工程技术的发展，使得人们可以设计并构建出灵活、功能强大和高质量的信息系统——基于MVC（Model-View-Controller）架构模式的B/S系统，就是一个成熟并且高效的结构。有很多技术都应用了MVC这一架构模式，JavaServer^TM Faces技术就是其中的一种，开发者可以利用JSF技术开发出设计良好的系统。

2  MVC架构模式

    MVC模式将系统分割为三个独立的部分：Model、View和Controller。Model代表应用数据和业务逻辑，View负责将数据显示给用户，Controller处理与用户的交互。三个部分松散地耦合在一起，通过变更通知机制来保持同步，其原理如图1所示：

图 1  MVC架构模式示意图    MVC模式使系统各部分之间的耦合度降低，内聚度提高。这种设计方式能够有效地提高系统的可维护性。    Web应用程序依赖于HTTP（超文本传输协议）。HTTP是一个无状态的协议，它本身没有提供会话状态保存机制。因此，适应于Web程序的MVC架构模式受到了一定的限制，同时也必须做一些修改，这就是Model 2模型。在这个模型中，有一个前端Servlet作为Controller，侦听特定的URL请求。在收到请求后，Servlet与作为Model的JavaBean交互，再决定向哪一个View转发请求，最终再显示给用户。其结构如图2所示：图 2 Model 2的结构图    HTTP的无状态性导致了这么一种结果：在Model 2中，Model的变更无法立即传播到相应的View和Controller。

3  JSF架构

3.1  JSF的结构

    JSF是为基于Java技术的Web应用程序所设计的服务器端用户组件框架，它基于Model 2架构，明确定义了Model、View和Controller，其结构如图3所示。    JSF的核心是建立在上述架构上的User Interface Model（用户界面模型）。这个模型直接决定了JSF架构不同于传统Web框架，它提供了基于事件的编程方式。用户界面模型由这几部分组成：    ●   User Interface Component Classes（用户界面类）：这些类代表了用户界面组件和用户界面组件相关的操作接口，如保存状态、维护引用、事件的处理和呈现组件等。    ●   Component Rendering Model（组件呈现模型）：组件的功能由组件的类决定，而组件的显示可以由专门的呈现器来决定。这种功能和呈现分割的设计意味着：可以通过简单地替换呈现器，获得不同的显示效果，或者通过不同的呈现器，来适应不同的客户端。    ●   Conversion Model（转换模型）：某些用户界面数据，如输入框中的数据，是与服务器端的数据对象相联系的。服务器端的数据对象是有类型的，而用户界面组件内的内容全部都是String类型的，如果这两者数据类型不相容，就必须有一个转换器。转换模型定义了这方面的内容，程序员可以根据需要为用户界面组件搭配合适的转换器。图 3 JSF结构图    ●   Validation Model（验证模型）：这个模型定义了如何对来自于请求的数据进行验证。程序员可以通过它定义数据的格式。    ●   Event and Listener Model（事件和监听模型）：通过事件和监听模型，JSF技术提供了基于事件驱动的编程方式——用户界面产生event（事件），注册在其上的ers（监听器）捕获这个事件，执行事先确定的任务。事件和监听模型提供了Listener类作为监听器的接口，一旦一个应用程序提供了对Listener类的实现，并且向相应的用户界面组件进行注册，就可以得到相应的通知。JSF支持三种事件：值变化事件、动作事件、数据-模型事件。

3.2  JSF的请求处理生命周期

    JSF系统的组成元素由用户界面模型来定义，这些元素如何协作则是由JSF的请求处理生命周期来定义的，这个步骤也被称为JSF页面的生命周期，如图4所示：

图 4 JSF页面的生命周期    ●   Restore View（恢复视图）：在这一阶段，JSF的服务器会为所接收的faces请求建立组件树，并将相应数据存入FacesContext实例中。在下一次访问这个页面时，FacesServlet将利用这些数据重建组件树。通过这种机制，可以在不同的请求之间保存数据，解决了HTTP本身无状态的问题。    ●   Apply Request Values（应用请求值）：在组件树建立之后，系统会从请求的参数中抽取参数值，将它们赋值给相应的组件，同时消息和事件会被存放于相应的消息或事件队列中。    ●   Process Events（处理事件）：系统将消息队列中的事件广播给相应的监听器，由监听器作相应处理。    ●   Process Validations（处理验证）：在这一阶段，系统读取组件的值，同时查看在相应组件上的验证器规则，通过比较值和验证规则，确定组件的值是否有效。    ●   Update Model Values（更新模型值）：将用户组件的值赋给相应的支持Bean。    ●   Invoke Application（调用应用程序）：在这个阶段，系统响应所有的ActionEvent事件，进行相应的处理。    ●   Render Response（呈现响应）：系统生成相应的响应，并将响应的状态保存起来，以便后续的请求进行访问。

 

4  持久层的架构设计

    本系统的持久层采用DAO（Data Access Object，数据访问对象）模式的设计。通过DAO模式对系统进行分割，将数据库访问层的实现封装到Data Accessor（数据访问器）中，从而将Domain Object（域对象）分离出来，实现了低级别的数据访问与高级别的业务逻辑的分离。    为了减少系统通过访问数据库的次数，在Data Accessor的设计上采用了Value Object + Persistent Object的设计思想。由于系统的复杂性，DO（域对象）通常不仅仅对应一个表格中的一条记录，它有可能对应多个条记录，甚至有可能对应于多个表格中的记录。在这样的情况下，使用VO就非常必要了。因为通过使用VO，可以将众多的常用的相关属性封装成一个对象，在一次网络传输中完成信息的获取和修改，减少了多次进行的网络传输开销。其结构如图5所示：图 5 DO、VO、PO关系图    PO对应于数据库中的真正记录，Data Accessor对数据库的实际操作都是封装在PO中的。PO实际上是数据库内信息在内存中的镜像，这是由信息在DO、VO、PO、数据库之间的流动方式来保证的：    ●   首先，PO在初始化时，必须从数据库中更新信息。也就是说，一旦PO完成了初始化，此时它的数据和数据库中的记录是完全一致的。    ●   其次，数据在更新时，其流向是DO → VO → PO → 数据库。因此在数据更新完成时，数据库和PO的数据仍然是同步的。    ●   接着，数据在被删除时，数据库中的数据和PO中的数据同时消失，仍然不会出现数据不同步的情况。    ●   最后，数据在受查询时，数据库没有受到改变，PO也没有受到改变。因此，查询完成后，数据库和PO的数据仍然是同步的。    所以，PO与数据库中的相应记录是同步的，完全可以视为数据库记录的镜像。鉴于这个特性，系统在查询时可以直接查询PO，无需通过网络访问数据库，这样就减少了网络开销和数据库查询开销。实际上，即使是系统在进行数据更新时，开销也和直接使用VO更新数据库一样。    使用PO还有一个好处：VO的数据类型未必能完全兼容于数据库中的数据类型，PO可以在数据库和VO之间进行数据的类型转换，这样，在VO和DO中就可以直接使用合适的数据类型了。    可以看出，VO + PO的Data Accessor设计方式有效地提高了系统效率。同时，Domain Object的分离使程序员可以专注于业务逻辑的设计，便于与JSF框架的对口。

5  系统设计

5.1  系统功能

    系统针对汽轮机厂大型设备（也被称为主机）的采购，其用户为生产单位、工厂计划处、装备资源处。系统需要为这些用户提供这几方面的服务：对采购订单的管理、设备信息的管理服务以及采购发票的管理。    对采购订单的管理要求系统能够提供以下功能：从生产单位收集采购需求、计划处审核采购需求、计划处整理采购需求、计划处创建采购订单、跟踪采购订单的执行情况（也就是采购合同的管理）。    对设备信息的管理要求系统能够提供以下功能：制定设备信息的档案、跟踪设备的情况、能够对设备进行转固、提供记录设备台帐的功能。对采购发票的管理要求系统能够提供以下功能：记录设备的发票记录，以附件形式保存发票的扫描记录。    同时，系统还要提供相应的查询功能。

5.2  系统分析

    通过收集、整理业务信息，得到了如图6的主机设备采购流程图。分析流程图，得到以下结论：    ●   系统应该建立四种用户角色：生产单位的普通用户、采购计划制定员、采购订单制定员、采购过程管理员。    ●   系统要制定以下几种表单来提交信息：主机采购申请表格、主机采购计划单、主机采购订单、主机采购信息跟踪表。    为了让系统追踪主机信息，必须在制定采购计划时为每一台主机设置一个系统唯一的编码——拟采购主机编码。这个编码是主机的标识符，在主机转固时，与真正的主机编码是一一对应的。同样的原理，通过这个编码，可以将将整个工厂的其它相关信息串联起来。主机的整个生命周期的信息都可以被追踪和记录。图 6 大型主机采购流程    ●   系统需要制定以下数据库表格来保存信息：采购申请表、采购计划表、采购订单表（采购合同表）、采购合同跟踪表、拟采购主机表。另外，还必须制定相关的参数码表。

5.3  系统实现

    以编辑主机信息为例，涉及的主要内容有：JSF页面、数据库表格、DO（域对象）、VO（值对象）、PO（持久化对象）。它们互相协作，完成相应功能。    JSF页面包含了表单控件<h：form>，使用JSF的<h：panelGrid>控件来布局。表单中采用了多种控件——日期输入框<t：inputCalendar>、文本输入框<h：inputText>等，通过<command：>控件来提交表单。数据库表格保存了拟采购主机的各项参数，如下所示：

图 7 数据库表格示例    PO由属性、访问器、构造器和数据库访问方法组成。PO的属性和数据库中的相应记录是对应的。其构造器和数据库访问方法使用JDBC API将数据库中的记录映射到相应的属性上。    当用户提交了相应的拟采购信息后，在JSF的请求处理生命周期的调用应用程序阶段，创建相应的DO——拟采购主机对象，同时建立相应的VO和PO，最后调用PO的create()方法在数据库中建立相应的记录。

6  结束语

    JSF是一个服务器端用户界面框架，它所提供的事件驱动的编程方式，极大简化了Web程序的用户界面开发。JSF技术结合DAO等设计模式，可以开发出高效率，高可维护性的Web应用程序。

1  Jennifer Ball， Debbie Carson， Ian Evans， Scott Fordin， Kim Haase， Eric Jendrock. The Java^TM EE 5 Tutorial， Sun Microsystems， Inc.2  Bill Dudney， Jonathan Lehr， Bill Willis， LeRoy Mattingly著. 孙勇，蔡云志译. Masting JavaServer^TM Faces 中文版， 出版社.3  David Geary， Cay Horstmann 著. 王军，马振萍等译. JavaServer Faces核心编程， 电子工业出版社.4  Erich Gamma， Richard Helm， Ralph Johnson， John Vlissides. 李英军，马晓星，蔡敏，刘建中等译. 设计模式，机械工业出版社。