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