(转)J2EE框架设计思路
一，导言
框架设计（FrameworkDesign）是系统设计的重要组成部分，一个设计优秀的框架是一个可扩展和可改变（迁移）系统的基础。本文针对常见J2EE分布式的信息系统（特别是B/S形式的系统），提出作者在框架设计上的观点和思路。
（一）问题和解决方法
目前应用J2EE技术构建信息系统的需求越来越复杂，开发周期越来越紧迫，同时对系统的稳定性、扩展性和可维护性要求也越来越高。那么如何满足客户对系统要求，加快我们的开发呢？信息系统需要一个持久化的存储设备（如：数据库）中存放和取回信息数据。当存储设备改变时，我们如何使系统支持这个改变，而不用重写我们的程序代码呢？已有的代码能不能在新的系统上重用呢？类似问题，给我们系统设计带来很大的挑战。
一个有效的解决方法是把信息业务信息按照应用功能模块拆分开：业务逻辑与数据库服务器分开，用户界面与业务逻辑分开。辟此相对独立，任一方任何改变都不会影响对方。这就是我们经常提到的三层概念。
*表示层（Presentation）
*业务逻辑层（BusinessLogic）
*数据存储层（Data）
表示层负责提供用户界面，业务逻辑层负责实现业务逻辑，数据存储层负责业务逻辑层中所有数据的持久的存储。
业务逻辑层在三层模型中具有很好的伸缩性，设计者往往根据系统容量、分发、部署等等情况再一步把业务逻辑层细分，从而产生了多层。这就是所谓n层体系结构。所以业务逻辑层也是我们系统设计中最重要的一块。
引入三层模型后，我们就可以针对这三层的特点定义出一种可重用的、可扩展的类集合，它通过标准的API来先外提供服务。这些类集合的划分和定义过程就是我们所要阐述的框架设计。
（二）框架定义及特点
什么是框架（framework）？框架可以定义为一组关系服务的可扩展、可重用的子系统。常见的软件框架有：MFC、VCL、JDK等等。其具有以下的特点。
*它是一个功能类的集合，类之间可以相互协作，为业务逻辑子系统提供服务。
*它包含了具体类和抽象类，这些类定义了标准的接口、对象间的交互作用和系统的相关常量。抽象类，可以包含抽象和具体的方法。
*为了利用、自定义或扩展框架的服务，通常需要框架的使用者去定义已存在的框架类的子类。
*框架中定义好的类只提供给用户自定义的类调用，而从不调用用户自己定义的类。
二，框架设计
对于一个分布式信息系统，我们通过上面的讨论，引入了三层的设计模型，现在就可以在这个模型上进行系统的框架设计了。但是，在开始设计之前先明确一下框架设计的目标。根据系统要求和框架定义，我们的目标为：
*类（组件、代码）最大化的重用。
*框架结构尽可能合理、简单和明了。
*框架要有灵活扩展性。满足用户的二次开发要求。
*框架要安全、稳定、高效率，可维护，可升级。
*框架中子系统（包）之间不应该存在双向性依存关系。
分布式信息系统三层设计模型中系统类的类型（Classes-Type）体系结构图如下所示：
图（一）
所以此框架设计为：
把分布式信息系统的框架总体划分为四个主体包，分别为：表示层的用户界面包（ui），业务逻辑层的业务对象包（bs），数据持久层的数据持久包（ps），系统资源层的通用实用包（su），结合公司自己的命名规范，具体的UML框架图可为如下所示：
图（二）
其中，“ProjectName”为信息系统项目的立项英文命名，如：国有资产管理系统，“ProjectName”为“sams”；“CompanyName”为公司的英文简称，如：翱拓系统集成，“CompanyName”为“auto”。
“ui”----用户界面包（UserInterface）。
“bs”----业务逻辑包（BusinessSession）。
“ps”----数据持久存储包（PersistenceStore）。
“su”----系统通用实用包（SystemUtility）。
下面将结合J2EE体系结构分别详细讨论各层包的框架实现问题。
（一）通用系统资源层框架设计
通用系统资源层框架设计，从我们上面定义好框架来看就是系统通用包su（SystemUtility）的设计。从图（二）可以看出，ui包、bs包和ps包都是从su包中调用接口，su包给它们提供服务。所以本层框架的设计是系统能否实现类（组件）重用的基础，是系统能否满足可靠稳定、高效率和可维护的关键。
既然是通用包，那么它具体提供哪些服务（或工具）呢？我们知道J2EE体系结构中也提供了许多标准的服务，如：JMS、EJB、JTA等等。那么su包是否也应该提供类似的服务呢？这些问题都没有统一的答案，这主要看项目系统分析和设计人员根据项目本身的特点和需求，应用什么样的技术和解决问题所运用什么样的设计思想和设计模式等因素有关。
值得一提的是，“框架是骨架，设计模式是肉”。设计模式思想影响框架的构成，一个框架中应用合适的设计模式来实现，才是框架精华的所在。在这一层，常应用到的设计模式有：结构型的Bridge模式、Facade、Proxy；创建型的Factory、Singleton和行为型的Strategy等。
根据作者的经验，结合J2EE体系结构的应用，通用系统资源层的框架可为：
图（三）
图（三）说明如下：
su包包含8个子包，分别为：
（1），resource包，包含标准接口访问J2EE中间件（应用服务器）资源的类。如：容器的JNDI服务等等。
（2），factory包，包含创建不同类型对象的接口的类，目的是有利于控制类创建，减少一些关键对象误用的风险。
（3），jms包，包装了有关应用J2EE消息服务的类。
（4），ui包，针对表示层封装一些标准通用的类。
（5），ejb包，引用Bridge设计模式，在EJB中加多一层封装，一般以后方便扩展和维护EJB，减少ejb编程的风险。根据ejb的类型，分session和entity两个子包。
（6），db包，包含有关访问数据库的类，包括：数据库连接池、报表和序列号等标准接口。
（7），log包，包含记录体统日志和调试应用的接口类。细分applog和appdebug两个包。
（8），exception包，根据系统的特性，自定义一套应用异常。
（9）tools包，包含了常用标准的系统函数类。根据这些函数的类型，分为：date、maths、format和constfunc四个包。
以上框架仅为参考，设计人员可根据自己的实际需要，来重新定义。
（二）表示层框架设计
表示层框架设计对应着我们定义的ui包框架设计。在针对J2EE体系结构做系统设计时，往往应用MVC（Model-View-Controller）设计模式来实现。MVC模式根据应用的角色对应用进行分解，然后使用不同的方法解决。
*Model，模型，系统应用的具体数据模型，不关心怎么表示和何时访问。只考虑数据的完整性和存储方式。与数据持久层对应，所以是我们数据持久层框架设计所关心的问题。
*View，视图，只关系如何表示的问题。本层讨论。
*Controller，控制器，控制器是解决何时访问的问题。是系统应用的业务逻辑，确定是否满足一定条件时，应用程序才能访问模型（Model）中的特定数据，然后根据情况把取得的具体数据委托给负责表示的视图（View）。与业务逻辑层对应，在业务逻辑层框架设计中讨论。
在J2EE体系中，AWT、SWING、JSP和Servlet都是针对表示（视图）而设计的。在实际应用中，我们经常根据系统不同的功能模块写JSP和APP客户端应用程序来和用户交互，所以在框架定义中可分为两个包，jsp包和app包；同时，有时候还需要定义一些系统常量和处理一些页面逻辑，所以我们也定义一个vbn（viewbean）包来存放这些页面类和常量类。所以表示层的框架设计可为：
图（四）
图（四）说明如下：
（1）jsp包，按信息系统不同的功能模块存放jsp程序文件。由于jsp文件类型不是java文件类型，所以此包可以当作目录处理，把其提出来，按照系统部署的要求，单独放在一个合理的目录下。其中JFunctionModule1、JfunctionModule2、JfunctionModule3等名称为信息系统具体的功能模块名称。可根据需要来定义和安排目录。
（2）app包，存放java客户端应用程序。其中AFunctionModule1、AfunctionModule2、AfunctionModule3等包名称为信息系统具体的功能模块包名称。根据客户端应用程序的所属关系，存放到具体的功能模块包中。
（3）vbn包，存放信息系统表示层的常量定义类和页面处理类。
最后，值得一提的是：在表示层的jsp页面开发中，为了避免把太多的代码和逻辑编写在同一个页码中，提高jsp程序的效率和可维护性，可以应用VC（View-Controller）设计模式，html为视图，servlet为控制器。当然还可以应用struts技术来实现，这里就不在讨论了。这应该属于具体的程序设计问题。
（三）业务逻辑层框架设计
业务逻辑层设计对应我们定义bs包的框架设计。是MVC模式的Controller（控制器），负责访问数据持久层，把返回数据提交给表示层，起到承上启下的作用。J2EE体系结构中，我们一般应用会话Bean来实现。
业务逻辑层设计在系统设计的详细设计中是最为复杂，工作量对大的一块。需要从系统分析中提取信息系统各个功能模块的用例（UseCase），再针对每个用例，应用UML语言详细绘画出此用例的顺序图（或协作图），然后根据实际情况决定是否使用有状态还是无状态的会话Bean。但是，此层的的框架设计却简单明了，其框架可为：
图（五）
在bs包下直接根据信息系统的功能模块的名称来定义子包。其中，bsFunctionModule为功能模块的英文名称。
（四）数据持久层框架设计
数据持久层对应MVC设计模型中的Model，其设计是信息系统设计的最重要部分，是系统的性能和是否可平移的基础，其设计好坏直接影响到项目的成功与否。数据持久层框架设计只有详细讨论数据模型设计后，才能比较好勾画出来。故本节准备探讨持久数据模型设计后，再实现其框架设计。
◆常见数据持久层设计类型
（A）在业务逻辑层的类中，直接使用SQL代码。如下图所示：
图（六）
*优点：
写代码的效率很高。
*缺点：
SQL代码到处出现在程序的类中；逻辑业务类与数据库直接耦合在一起，这意味着任何小的改动都导致程序原代码的修改。
*结论：
对于小型应用程序是可行的，对于企业级的系统，这种在逻辑业务类中写死SQL的方法，会导致代码难于维护和扩展。
（B）SQL代码封装在一个或多个数据代理类中。如下图所示：
图（七）
*优点：
在业务类和数据库之间加多一层封装，是系统的可维护性大为提高。这种方法包括可以利用数据库存储过程、SQLJ以及微软ADO数据访问的策略。
*缺点：
对数据库进行任何一点的改动都会直接影响到数据代理的代码，也就是程序原代码还必须改动。
（C）不用写SQL代码，对数据库的访问完全通过具有鲁棒性数据持久层来实现。如图所示：
图（八）
所谓的鲁棒性数据持久层至少要满足下面的条件：
（1），支持关系数据库的高级的特性。（如：事务、存储过程、游标）
（2），支持对象和关系之间的映射，用户不直接用SQL与数据库交互。
（3），支持多连接，支持数据库连接池。
（4），支持多种体系结构，支持不同厂商的数据库。
*优点：
应用程序开发人员不需要了解数据库结构，甚至也没必要知道对象如何保存在数据库的。有利于组织开发大规模的针对关键业务的信息系统。系统的迁植性、可维护性和扩展性好。
*缺点：
由于对数据库的访问交给了持久层处理，理论上对系统的性能上有些影响。
◆具体选型
上面列出了常见的数据持久层的几种类型，那么我们究竟应用那种类型比较合适呢？这需要根据系统规模和需要的具体情况来决定。在J2EE体系结构中开发系统，我们应该选择（B）和（C）两种数据持久层比较合适。
在J2EE体系结构中，类型（C）鲁棒性数据持久层可以应用EJB的容器管理实体Bean（CMP）来实现，在EJB2.X中CMP就是为了实现鲁棒性数据持久层而制定的标准规范。开发人员不必在CMP中编写SQL代码，一切和数据库的交互都交给EJB容器去负责。由于J2EE是开放、标准规范，所以，CMP组件可以在EJB容器与数据库之间移植。
在实际的信息系统开发过程中，我们往往需要处理一些复杂的查询或报表，而这些查询数据往往来源于多个数据表，而且其查询结果的实体对象的观念性不强。这个时候，我们用CMP去封装它就显得有点无能为力了。因为理论上实体Bean毕竟代表了数据库表里面的一行数据。
遇到这种情形，数据持久层的设计采用类型（B）就比较合适了。我们可以用EJB的无状态会话Bean来实现这层的封装。通常的利用Bridge设计模式来实现：
（1）建立数据访问对象DAO（DataAccessObject）接口。定义数据源的抽象操作行为，提供方便访问和维护数据的标准API结构。
（2）实现数据访问对象接口。DAOImplementor。实现具体DAO接口的内容，根据应用的数据源类型不同，可以有针对多个数据源的实现（如：DAOImplementorSQLServer，DAOImplentorOracle等等）。然后应用Adapter设计模式，将特定的数据源驱动接口分配到DAO中去。
（3）建立EJB调用DAOImplementor，实现业务逻辑。
如下图所示：
图（九）
◆框架设计
通过，上面的讨论，我们数据持久层（ps）包的框架可为：
图（十）
ps包下按信息系统的功能模块来划分子包（如：上图分了3个功能模块包，PfunctionModule1、PfunctionModule2和PfunctionModule3），每个功能模块包再分：
be（businessentity）包，包含业务实体对象（数据库关系映射对象），DAO定义接口等等。
eb（entitybean）包，包含实现数据持久层的实体组件。
sb（sessionbean）包，包含实现数据持久层的会话组件。
三，概述
系统框架设计不是一成不变的，往往根据系统设计师的对某个信息系统的见解不同，框架也有所差别。但是要设计一个好的框架，除了有明确的设计目标外，关键在于：需要调查和研究系统同类产品的状况及相关的技术特点，了解目前流行技术对此产品所能提供理论和技术支持情况，结合自己产品的特点，才能逐步勾画出整个产品项目的框架蓝图。
四，参考书目
《MasteringEnterpriseJavaBeans》EdRoman
《DesignofaPersistenceLayerSeries》
《UML和模式应用》CraigLarman