摘 要 设计企业bean应用时，实体bean的目的不是代表对象模型中的每个持久性对象。实体bean更适合于粗粒度的持久性业务对象，使用复合实体模式可以设计粗粒度的持久性业务对象。本文介绍了目前流行的mis系统整体架构设计，分析了某学院mis系统b端学生信息管理模块中的数据库模型，接着说明将复杂的对象模型直接映射到实体bean模型时产生的细粒度实体bean问题。给出了在mis系统中细粒度实体bean问题的解决方案——复合实体设计模式及相关的会话外观和值对象设计模式。
关键词 粗粒度实体bean；细粒度实体bean；设计模式；复合实体；会话外观；值对象
1 引言
j2ee(java 2 platform，enterprise edition)是sun公司定义的一个开发分布式企业级应用的规范。它提供了一个多层次的分布式应用模型和一系列开发技术规范。j2ee技术之所以赢得广泛重视的原因之一就是ejb(enterprise javabean)。它们提供了一个框架来开发和实施分布式商务逻辑，每个ejb是按功能逻辑划分的，开发时不必关注系统底层细节问题，只关注具体的事务分析。WWW.11665.cOmejb有三种类型：会话bean(sessionbean)、实体bean(entity bean)和消息驱动bean(messagedriven bean)。实体bean代表数据库或另外一个企业应用系统中的数据对象。如代表数据库的一行记录。实体bean不包括商务逻辑，它们只是数据模型。因此，在ejb中设计一个实体bean时，需要考虑的重要选择之一就是：你是设计一个粗粒度(coarse-grained)的实体bean，还是一个细粒度(fine-grained)的实体bean。粗粒度一般表示类别级(the type of object)，即仅考虑对象的类别，不考虑对象的某个特定实例。比如，用户管理中，创建、删除对所有的用户都一视同仁，并不区分操作的具体对象实例。细粒度表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。通常，决定到底该采用粗粒度还是细粒度是很难的。这最好通过统一建模语言(unified modeling language，uml)模型中的模型化关系来决定。
2 信息化管理系统(mis)整体架构设计
图1 mis系统整体架构设计(bs和cs混合结构)
目前，大多数院校开发的信息化管理系统在整体上采用b/s(brower/server)和c/s(client/server)混合结构。其中b(brower/server)端，即web应用部分一般采用基于j2ee(java 2 platform enterprise edition)的三层架构，即将表现层、中间层和数据层分开，将所有的商业逻辑和工作流放入服务器端。在中间应用层中，采用以ejb(enterprise javabeans)为中心、servlets做控制、jsp(java server pages)负责呈现逻辑的mvc(model-view-control)结构，即模型－视图－控制器结构(如图1所示)。mvc结构把功能模块、显示模块和控制模块分离，使各部分之间协调工作、耦合性较小。ejb负责业务逻辑部分。为了使系统开发与维护更具有可操作性，使系统的体系结构更清晰，软件开发中将业务逻辑划分为应用逻辑和商业逻辑两个部分，其中应用逻辑部分负责用户的请求，商业逻辑部分负责与数据库服务器的操作。应用逻辑以应用的需求条件调用商业逻辑，商业逻辑将相应结果再返回给应用逻辑。业务逻辑功能的划分使ejb的处理更加自如，缩短开发周期，提高开发质量。同时也提高了系统的可复用性。
3 mis系统中数据模型的分析
3.1 模型分析
设计ejb层，首先必须了解它的数据模型。如某学院mis系统b端共有用户登录、课程查询、培养方案查询、学生信息管理、教师信息管理、学生选课管理等6个功能模块。其中学生信息模块——学生信息繁多，关系复杂。该学院学生有三类：本科自招生us(undergraduate student)、本科转专业学生csus(change specialty undergraduate student)、硕士研究生gs(graduate student)，每类学生包含六大类信息：基本信息(basic information)、奖罚信息(rewards punishment record)、学籍变动信息(status change record)、课程成绩信息(course)、班级(class)、研究方向和专业(study direction and specialty )。每大类信息包括各种类型学生对应的详细分类信息。
各实体、视图之间的整体关系如图2所示。
图2 某mis系统学生信息管理模块实体关系图
3.2 细粒度实体bean问题
在ejb应用时的一个常用经验是把对象模型直接映射到实体bean，也就是说，对象模型中的每个类被直接转换成一个实体bean。随着企业bean数目的增加，容器和网络负载也会同步增加。这类映射也把表间关系(又称主关键字/外部关键字)实现为实体bean到实体bean的关系。这将会对应用的性能产生负面的影响。
对象模型直接映射到实体bean的设计方法对于实体关系比较简单的模块(如前述系统b端中的用户登录模块、教师信息模块、培养方案查询、课程查询等)的设计实现是最佳的。因此这些模块开发时使用了容器管理持久化cmp(container managed persistence)实体bean技术对所用到的表进行了映射，原因是这些数据结构相对简单，数据单纯，不需要进行非常复杂、多样的查询，系统对数据表的操作不频繁，通常情况下对性能不敏感，故采用了cmp实体bean技术。cmp中只提供最基本的查询方法，所有的程序逻辑都封装在对应的会话bean中，会话bean和cmp一同部署，故可以采用本地接口访问实体bean，提高效率。客户端仅仅与会话bean进行交互(会话外观设计模式)。该设计的好处是隐藏了数据逻辑，mvc的结构非常清楚，后期的数据维护也比较简单。
但是对于像学生信息管理模块和学生选课管理这样实体关系复杂，对象数目众多的模块来说，将导致大量的细粒度实体bean。将严重影响应用的可扩展性，故使用bean管理的持久性bmp(bean managed persistence)实体bean技术，但需要开发人员编写持久性代码而容器只是确定何时执行该代码。
在学生信息模块中(如图2所示)，三种基本信息表(gsbainf，usbainf，csusbainf)与其对应的家庭成员社会关系(gsfamsorel，usfamsorel，csusfamsorel)、学习工作经历(gslewoexp，uslewoexp，csuslewoexp)、奖惩记录(gsrepurec，usrepurec，csusrepurec)、学籍变动记录(gsstachgrec，usstachgrec，csusstachgrec)、班级(cla)、研究方向(studdir)之间的表关系如果直接映射到实体bean时，会产生很多问题，也就是说细粒度实体bean会影响许多领域：一是影响实体关系，把对象模型直接映射到实体bean，会将对象间的关系转换为实体bean之间的关系。结果是一个实体bean往往包含或持有对其它实体bean的远程应用。这样在增加代码的复杂性之外，它还会降低系统的灵活性；二是影响可管理性，细粒度实体bean会导致系统中存在大量的实体bean。容器会创建大量对象来支持每个实体bean实例。大量的实体bean会产生更多需要维护的代码和类。这样会对应用程序的性能产生负面影响；三是影响网络性能，细粒度实体bean潜在地有更多的实体bean之间的关系，关系数的增加肯定会导致远程调用的增加，结果是由于网络负载而降低系统的可扩展性；四是影响数据库模式依赖，当实体bean是细粒度时，每个实体bean实例通常都被看作数据库中的一行，客户端使用这些细粒度实体bean时，它们实际上操作在数据库中的行层次，则客户端就变得对数据库模式很依赖。
4 在mis系统中的解决方案
4.1 把实体bean设计并实现成具有根和依赖对象的粗粒度对象——复合实体
4.1.1 复合实体及其相关概念
如果把学生信息模块的对象模型直接映射到实体bean，将导致大量的细粒度实体bean。从而带来网络负载、数据库模式依赖及管理复杂等问题。
为解决细粒度实体bean问题，在学生信息模块ejb的设计中采用复合实体的设计模式。
复合实体(composite entity)表示、模拟和管理一组相互管理的持久性对象。持久性对象是保存在某种类型数据存储中的对象。多个客户端通常共享持久性对象。持久性对象可以分成两类：粗粒度对象和依赖对象。使用“复合实体”对于一组相互联系的持久性对象进行建模、表示和管理，而不是按照个别细粒度实体 bean 表示它们。复合实体 bean 代表一个由一组对象构成的图。通过复合实体模式，可以减少数据库模型的依赖性、提高网络性能、消除实体间的依赖性。
复合实体模式的角色有：复合实体、粗粒度对象和依赖对象三种。其中复合实体通常是粗粒度对象或者持久粗粒度对象的引用。粗粒度对象拥有自己的生命期，管理与其它对象的关系。它可以被包含在复合实体里，同时复合实体本身可能就是粗粒度对象。依赖对象是依赖于粗粒度对象的对象，其生命期由粗粒度对象管理。
学生信息模块中复合实体的业务对象类图如图3所示。
图3 学生信息模块复合实体类图
4.1.2 实现复合实体的不同策略。
实现复合实体模式时存在许多策略。根据学生信息模块特点，在设计复合实体时采用了复合实体包含粗粒度对象策略和复合值对象策略和滞后加载(惰性加载)策略等三种策略。
在学生信息模块复合实体的开发中应用了复合实体包含粗粒度对象策略，在该策略中，复合实体(studinfentity)包含三个粗粒度对象(gsbainf，usbainf，csusbainf)。粗粒度对象继续保持与其它依赖对象(gsfamsorel等)之间的关系如图3所示。
值对象是任意的可串行化java对象。在学生信息模块复合实体中通过应用值对象策略(如图4所示)，可以创建必需的值对象(gsbainf)。对于复合实体(studinfentity)，客户端可以只用一个远程调用getgsbinf()来获取全部所需的信息。根据客户端请求数据的不同，值对象既可以是一个简单的对象，也可以是拥有子对象的复合对象。值对象被串行化，并且按照值顺序传递给客户端。值对象只充当一个数据传输对象；它不负责安全、事务、和业务逻辑。值对象把所有信息打包进一个对象，使用一个远程调用来获取信息，而不使用多个远程调用。一旦客户端接收到该值对象，则来自客户端的对值对象的进一步调用相对该客户端来说都是在本地执行的。
一个复合对象可以由其对象树中的多个层次的依赖对象组成。当ejb容器调用复合实体的ejbload()方法时所有的依赖对象都需要加载，这个过程会花费大量的时间和资源。一种优化策略是通过使用滞后加载策略来加载依赖对象。当ejbload()方法被调用时，首先只加载那些对复合实体客户端最关键的依赖对象。接着，当客户端访问尚没有从数据库中加载的某依赖对象时，该复合实体就执行一个即时加载。ejb2.0提供滞后加载策略。
4.2 会话外观
从实体bean中抽取和移动操作其他实体的业务逻辑，并集成到一个会话bean——会话外观。
4.2.1 会话外观模式
通过把实体bean和会话bean结合在一起，能够减少网络调用等开销，会话bean替远程客户端执行大批crud(创建、读取、更新、删除)操作。会话bean也作为一个事务的外观进行服务，强制事务在服务器上执行，而不是牵涉到一个远程客户端。这就把实体bean嵌入到会话bean的具体实现中去了。外部的客户端永远注意不到实体bean。这种方法的最终好处是使实体bean具有高的重使用率。
采用会话外观的设计模式把应用逻辑(业务对象)实现为会话bean，商业逻辑被实现为实体bean。从实体bean中抽取和移动操作其他实体的业务逻辑，并集成到一个会话bean，如图4所示。
在学生信息模块中。与实体bean相关的工作流被封装在busersession会话bean中。会话外观是一个粗粒度对象，其中该对象通过管理业务数据和业务服务对象交互以允许对工作流进行封装(如图4所示)。
图4 mis系统学生信息管理模块复合实体顺序图
4.2.2 总结会话外观模式优点
会话外观是在mis系统中使用的最多的一种ejb设计模式。即将实体bean层包装在一个称为会话外观的会话bean层中，客户端只能访问会话bean而不是实体bean。客户端和服务器之间的边界被一个会话bean层分开，它的方法将映射为应用中的所有用例，并且包含了这些用例的业务逻辑。采用会话外观可以隐藏业务组件之间所有的复杂交互活动，向客户端提供一个更简单的接口。通过网络跨越服务层而被直接暴露给客户端的业务对象的数目也会减少，避免把低层业务对象直接暴露给客户端，使两个层之间的紧密耦合最小。采用会话外观还可以提供统一的粗粒度服务层，以分离业务对象实现和业务对象抽象。向客户端隐藏业务组件之间的低层交互和相互依赖关系。这样做会提供更好的可管理性、交互(职责)的集中化、更大的灵活性，以及更大的对付变化的能力。
5 结论
实体bean最适合用作粗粒度事务持久性业务组件。而使用实体bean来表示细粒度对象会增加整体网络通信和容器负载，而且将影响应用性能和可扩展性。为解决细粒度实体bean问题，在系统开发中采用了复合实体和会话外观两种设计模式相结合的方法，可以减少数据库模型的依赖性、提高网络性能、消除实体间的依赖性。在复合实体模式中采用了复合实体包含粗粒度对象策略和复合值对象策略和滞后加载(惰性加载)策略等三种策略，可串行化粗粒度对象和依赖对象树。使用会话外观可管理实体bean之间的关系，可以隐藏业务组件之间所有的复杂交互活动，向客户端提供一个更简单的接口。
参考文献
[1](美)floyd marinescu著《ejb设计模式》[m]机械工业出版社[3-9页]
[2] 刘晓华等编著《j2ee企业级应用开发》[m]电子工业出版社[258-260页]
[3](美)deepak alur john grupi著《j2ee核心模式》[m]机械工业出版社[198-217页]
[4](美)ed roman著《精通ejb》[m]电子工业出版社[250-253、264-265页]
[5] kyle gabhart 著《持久数据管理——比较 java 数据对象和 ejb 技术》j2ee 探索 系列 网上期刊[j-ol]
