基于JavaServerTM Faces和DAO模式的大型设备采购系统
发布时间：2015-07-13 09:46
摘 要 文章先介绍了JavaTM EE家族中的重要成员——JavaServerTM Faces这一技术。它位于JavaTM EE的Web层面，为Web程序员提供了基于组件和事件驱动的编程方式，这将改变传统的Web程序编写方式。然后，本文分析了大型设备采购系统的固有特性，并介绍了如何结合JSF技术和DAO模式开发大型设备的采购系统。
关键词 JavaServerTM Faces；JSF；大型设备采购；信息系统
1 前言
信息技术、计算机网络技术、数据库技术和软件工程技术的高速发展，使得计算机信息系统得到了长足的进步。高速网络和大型关系数据库的成熟，为构建计算机信息系统提供了良好的基石；软件工程技术的发展，使得人们可以设计并构建出灵活、功能强大和高质量的信息系统——基于MVC（Model-View-Controller）架构模式的B/S系统，就是一个成熟并且高效的结构。有很多技术都应用了MVC这一架构模式，JavaServerTM 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（事件），注册在其上的listeners（监听器）捕获这个事件，执行事先确定的任务。事件和监听模型提供了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 JavaTM EE 5 Tutorial， Sun Microsystems， Inc.
2 Bill Dudney， Jonathan Lehr， Bill Willis， LeRoy Mattingly着. 孙勇，蔡云志译. Masting JavaServerTM Faces 中文版， 电子工业出版社.
3 David Geary， Cay Horstmann 着. 王军，马振萍等译. JavaServer Faces核心编程， 电子工业出版社.
4 Erich Gamma， Richard Helm， Ralph Johnson， John Vlissides. 李英军，马晓星，蔡敏，刘建中等译. 设计模式，机械工业出版社。
下一篇：基于视频的车辆检测与跟踪技术综述