|
在开始阅读本文之前,我们首先来看一个动画演示:case_system_demo.swf
该Flash演示了一个简单的客户-案例管理系统雏型,通过该系统,我们可以方便地添加,修改,删除客户以及对应的案例明细。我们这里之所以选择该系统作为演示实例,目的并不是要深入阐述客户-案例管理系统的业务背景,而是从业务-数据模型的角度来概括我们在企业级应用开发中经常会用到的一类模型,看到这里有些朋友可能会想,“这不就是UML或CMR中的一对多关系吗,有什么特别的?”。诚然,从本质上讲,这就是一种简单的一对多关系(O2M),这种关系在各类业务系统乃至数据库教科书中都屡见不鲜,但是很长一段时间以来,我们在具体的项目开发中往往还是停留在关系建模这个层次上,并没有很深入地研究过采用合适的组件技术来实现这样一种通用的业务模式。注意到这里引入了一个业务模式的概念,那么什么是业务模式呢?
业务模式在不同的语境下有不同的含义。在本文中,业务模式是指对众多业务用例模型和业务对象数据模型的抽象概括,业务模式有以下三个特点:
1.抽象性
我们可以把业务模式想象成是具有公共特征的业务对象模型的基类。这一点和UML中的关系模型和J2EE CMR中的关系模型非常相似,它们都是对现实世界中各个对象之间关系的高度概括,然而,业务模式扩充了上面简单的对象关系模型,具体的关系抽象级别如下图如示:

我们可以清楚地看到,业务模式的关系抽象级别位于中间层,它扩展了UML或J2EE CMR的一般关系,但又远不会像具体的业务对象模型关系那样复杂。
2.复用性
高度可复用性是业务模式的另外一大特点,通常我们在做系统设计时经常会按照业务用例设计=>业务对象模型=>类图映射这几个步骤,这样经常会发生这样一种现象,那就是大家都会隐约觉得一些特征很相似的业务对象模型经常会重复出现,但是我们还是要根据标准的规范,一一为该模型设计相应的若干组件以及定义类实现,这样无形之中会浪费掉大量的时间。因为这种常规开发模式的复用级别还停留在开发阶段的组件复用上,要实现真正的高度可复用性,我们应该在业务对象模型这一层就开始运用复用思维。换句话说,在采用了业务模式复用后,我们在设计E-R图时就可以考虑从现有的业务模式中去挑选匹配的模式及已封装好的实现组件了。
3.持久性
因为业务模式把主要的精力放在研究并实现服务端实体之间的抽象关系上,因此这里所指的业务模式100%都会涉及到O/R映射,不涉及O/R映射的组件我们只能把他看成是纯粹的业务功能模块,比如只包含合法性验性等功能的服务端组件,
既然业务模式有如此众多的优点,那么我们该采用何种组件技术来封装业务模式呢?首先我们来看一种最常见的服务端组件设计模式:Stateless Session Bean+Entity Bean
流行的未必就是最好的
J2EE发展到今天,几乎所有的应用开发人员都熟悉了一种设计模式,那就是Stateless Session Bean+Entity Bean,简称SSB+EB,具体地说,就是采用SSB包装主要的业务方法,采用Value Object包装输入输出参数,对于小批量,简单的增,删,查采用Entity Bean来实现,大批量的增,删,查则用SSB+JDBC直接实现。从设计模式本身和应用性能角度来看,这确实是一个很优异的开发方案。然而对一个开发人员来说,他不仅仅会关心该方案所带来的组件结构和应用性能上的提升,同时他也期望这是一套能显著提高自己开发效率的解决方案,并且大部分开发的组件都应具备很好的业务模式适用性,这样便可以在以后类似的项目中实现高度复用。但遗憾的是,在采用SSB+EB的情况下,由于一种业务模式至少会采用两个组件来实现,而且EB是和具体的数据表绑定在一起的,这样业务模式的可复用性就打了很大的折扣,此外开发过程中也会存在相当一部分重复劳动,比如我们经常会在SSB,Value Object,Entity Bean,Deploy Descriptor中反复检查并同步大量的get,set字段方法签名,如果字段数量成十上百,这无疑将是一件相当费时乏味的工作。如何找到一种既能利用EJB容器提供的各类服务,又能实现良好的业务模式复用,同时也可以在很大程度上提升开发人员效率的组件开发方案呢?我们开始把视线转向Workshop的Java 控件。
- Workshop JAVA控件
首先要明确一个概念:WebLogic Workshop JAVA 控件是运行在WebLogic Server服务端的组件,它不是EJB,但它确实运行在EJB容器的上下文中,因此享有EJB容器所提供的安全与事务等基础服务。我们在这里选取Java 控件而不是EJB作为实现业务模式的载体,主要是基于它的两个优点:
1.拥有比EJB更为灵活的业务模式封装能力。
2.拥有一个可视的开发和复用框架,能大幅度提高开发人员的效率
通过Java控件,我们可以轻松实现“业务模式 = > JAVA控件”的简单映射,下图很好地诠释了面向业务模式的开发策略:

这样我们只要在平日的项目开发不断发掘各类业务-数据模型,并抽象出各类业务模式,
就能不断完善现有的业务模式库,从而实现真正意义上的跨项目,跨团队的业务模式复用。
面向业务模式开发的最佳实践 - O2M (One2Many) 业务模式
现在让我们回顾本文开始处提到的O2M模式,看看O2M业务模式是如何通过Java控件来实现的。
一.O2M业务模式的发现
发现业务模式主要来自于对现实世界中大量项目中业务用例模型的抽象分析, O2M模式虽然很简单,但它确实也遵循了相同的过程。我们不难发现在大量的业务系统中,都会有持久化一对多实体关系的需求,无论是一个复杂的销售单证系统还是一个简单的CASE管理系统。
O2M业务模式的分析用例如下图所示:

E-R图如下所示:

二.漫游O2M业务模式的JAVA 控件实现
在本文中,业务模式的实现过程本质上就是一个定制Workshop Java控件的过程,现在就让我们通过一步一步安装附件提供的业务模式实验室,来进一步了解O2M业务模式的JAVA 控件实现机制。
1.配置开发环境并安装Lab模板
1.1 确认 BEA WebLogic Platform 8.1.2 中文版已成功安装
1.2 利用BEA自带的[Configuration Wizard]创建一个Basic WebLogic Workshop Domain,用户名和密码均为weblogic,域名采用默认的workshop
1.3拷贝本文附件中的business-pattern-lab.zip到如下路径
<install_dir>/bea/weblogic81/workshop/templates
1.4启动Workshop,选择 [文件]à[新建]à[应用程序]à[全部],此时我们将看到一个名为“业务模式实验室”的模板,如下图所示:

这里我们命名为 BPLabDemo,服务器选择在1.2步中新建的workshop domain,点击
[创建]退出。
2.现在我们可以看到一个完整的Lab应用结构

整个Lab由一个Java控件工程(BPControl)和一个WEB应用工程(BPLab)构成。目前控件工程中只定义了一个实现One2Many业务模式的控件
3.双击打开One2ManyImpl.jcs,从右边的JCS设计视图中我们可以看到O2M控件总共定义了九个接口方法,这九个方法完整实现了我们为O2M业务模式定义的所有用例
| 方法名 | 说明 |
| addNew |
新增一笔基本数据和多笔明细 |
| delete |
删除一笔基本数据 |
| getBaseTemplate |
得到基本数据的实例模板(包含元数据) |
| getBases |
根据查询条件查询数据 |
| getDtlTemplate |
得到明细数据的实例模板(包含元数据) |
| open |
根据主键获取一笔基本数据和多笔明细 |
| openBase |
获取基本数据 |
| openDtl |
获取明细数据 |
| update |
更新一笔基本数据和多笔明细 |

4.方法有了,那么自定义属性该如何处理呢?对于此类问题,我们通常采用的一种方式是用.properites或.xml文件定义一系列属性配置文件,然后通过JAVA IO进行读取。这套方法确实实用,但缺点同样也很明显,配置文件的数量和大小往往与项目的规模和应用的实例成正比关系,在一个大型的企业级项目中,如何管理这些配置文件经常会成为一件令开发和项目管理人员都十分头疼的事情。现在让我们来看看Workshop是怎么做的,打开One2ManyProperties.xml,我们会看到O2M控件的一系列自定义属性描述:
| 方法名 | 说明 |
| datasource-jndi-name |
JNDI数据源名 |
| datasource-schema |
数据源的模式 |
| base-table-name |
基表名 |
| dtl-table-name |
明细表名 |
| base-table-pk-name |
基表主键名 |
| dtl-table-pk-name |
明细表主键名 |
| dtl-table-fk-name |
明细表外键名 |
虽然同样也是一个xml配置文件,但大家可能会注意到,在该文件里仅有属性描述,没有名值对。那么我们应该在哪里为控件的实例提供真正的参数值呢?
5.双击打开BPLabcallcenterContoller.jpf,选择操作视图,然后选中 bpControl控件,我们终于在右边的属性编辑器中看到了在One2ManyProperties.xml中描述的一系列自定义控件属性。如下图所示:

现在一切都变得很明朗了,为了实现O2M业务模式的最大复用,所有的自定义参数值都是通过控件实例的属性编辑器来动态配置。因为对于O2M业务模式而言,数据源的JNDI名称可能会变,表名可能会变,主键,外键名可能会变…….,唯一不变的就是O2M关系本身,所以我们就把它做成了可以复用的Java控件,这一切都显得非常和谐自然。
最后让我们进入Business Pattern Lab,运行O2M业务模式的演示实例
三.运行业务模式演示系统
1. 创建演示数据库
1.1 选择 [工具]à[WebLogic Server]à[启动WebLogic Server]
1.2 WebLogic Server一旦成功启动,workshop domain集成的pointbase数据库也处在了运行状态,现在我们打开PointBase数据库的管理控制台,它的启动脚本路径是:
<install_dir> \eaweblogic81commonevalpointbase oolsstartPointBaseConsole.cmd
确认URL如下图所示,用户名和密码均为weblogic,选择ok进入控制台

1.3接下来我们在Pointbase Console中新建一个演示Schema,选择左边树状菜单中的[SCHEMAS]à[CREATE SCHEMA],输入BPDEMO,保存退出
1.4选择[FILE]à[Open…],定位附件中的initdb.sql,按F5执行数据库初始化脚本
2. 编译并部署应用
按F7对当前的Lab应用程序进行编译,编译成功后workshop运行时框架将会自动部署当前应用到正在运行的WebLogic Server上。
3. 运行演示系统
打开IE或workshop测试浏览器,运行如下的URL
http://localhost:7001/BPLab
此时我们将会看到本文开始处演示的CASE系统界面。
四.关于O2M业务模式的复用
O2M业务模式的复用非常简单,整个O2M JAVA控件不用作任何修改,比如现在我们想再创建一个销售单据管理系统,由于销售单据也分为基本数据和明细数据两个部分,这又是一个典型的O2M关系,因此我们只需要在数据库中创建好所有的表,然后在销售单据管理的JPF中声明一个该控件的实例,配好控件的自定义参数,再设计两个对应的FormBean及相关的JSP页面就ok了,整个过程非常简单。
五.O2M业务控件在将来的增强
目前整个O2M业务控件比较简单,将来还会陆续加入懒惰加载,级联删除,处理多张明细表等实用功能。
本文系统地介绍了面向业务模式的Workshop J2EE RAD开发理论及相关策略,并以一个实际的O2M业务模式为例介绍了其中一些具体的实现细节,最后演示了一个构建于此模式之上的一个简单的CASE系统,由于时间仓促,疏漏之处在所难免,还请广大朋友批评指正。最后我想说明的是,本文的目的在于抛砖引玉,推出业务模式实验室的目的也是为了能够积聚更多对此感兴趣的朋友,我相信只要大家一起努力,在平时的项目开发中不断发现并积累各类业务模式,再加上BEA Workshop 的强大RAD功能,J2EE应用的开发从此将会变得更加轻松自如。事实上,现在我们已经尝到一些小甜饼了…….
本文附件下载 BPLab_Attachment.zip |