J2EE框架设计技术分析

设计目标：

1. 开发效率

2. 性能、预算

3. 符合OO设计

4. 避免复杂性

5. 可维护性、可扩展性，可重用性

分布式应用

不足：

1． 增加了应用的复杂性

2． 对性能会造成一定的影响

3． 给OO Design带来一定的困难

优点：

1． 能满足多类型客户端的需求（applet, swing）

2． 能同时将组件部署到不同的应用服务器

采用前提：

1． 客户端需要使用J2EE技术，比如Swing

2． 为了与已有的分布式应用集成

3． 需要将J2EE组件部署到多个应用服务器

4． 实现对多应用组件部署进行控制，提高系统灵活性、可靠性

可选技术：

可通过集群和负载平衡（remote interface调用单服务器应用）来实现分布式应用的健壮性、灵活性

EJB技术

缺点：

1． 测试困难

2． 部署麻烦（classloader复杂、部署描述符复杂、开发－部署－测试周期长）

3． 采用remote interface的EJB不符合OO Design

4． 技术复杂，可能将简单需求变得复杂开发

5． 减少了应用服务器的选择

优点：

1． 能远程访问组件

2． 能将应用组件部署到不同服务器（分布式应用）

3． 支持多客户端访问

4． 使用到异步消息模式的时候可以采用message driven bean

5． 能实现复杂的事务管理

采用前提：

1、 对EJB底层比较熟悉

2、 需要使用EJB的角色安全访问

3、 需要使用EJB的事务管理

4、 需要使用EJB的线程安全管理

5、 需要使用基于RMI/IIOP的分布式架构

4种J2EE基本框架

一．非分布式框架

1、(Web UI tier + Business Logic tier) + implement tier + DBMS

实现简单、能满足大部分需求，是中小型J2EE项目中采用最多的框架，虽然没有使用EJB，但是层次清晰。

优点：

1．简单

2．速度快

3．符合OO设计

4．容易测试

缺点：

1．仅仅适用于Web UI

2．自己管理事务

3．无法实现高并发处理

4．无法使用entity bean

5．不支持多JVM应用

2、Web UI + local EJB + DBMS

稍微复杂，能使用EJB容器的事务，线程管理，没有采用分布式特性，性能比远程调用稍好

优点：

1．降低了EJB的复杂度

2．不会对基础框架造成影响

3．本地调用对性能有一定优势

4．可以使用EJB容器的事务和线程管理

5．可以使用entity bean

缺点：

1．比纯web应用复杂

2．单JVM运行

3．单客户端（web）支持

4．测试困难

二．分布式框架

1．基于远程调用的分布式

架构最复杂，对有远程访问客户端的需求是理想选择，健壮、灵活，但是不容易维护、测试、实现困难

优点：

1． 多客户端支持

2． 可将应用组件部署到多台服务器（JVM）

缺点：

1．增加了复杂度

2．影响性能

3．调试困难

4．必须在EJB容器中运行

5．异常处理复杂

6．OO设计困难

2．基于Web Service的分布式

对非J2EE客户端调用适用性好，无分布式调用，往往作为第一、第二架构的变体。

优点：

1． 通用标准，能支持更多客户端类型

2． 提供的Web service接口比RMI接口更好

3． Web service传输协议比RMI更友好

缺点：

1． 性能差

2． 需要作object与xml之间的转换

3． 相对于java client来说，性能也不好

UI框架部分

选择UI的几个决定性因素：

1． 用户的实际需求

2． 项目的性能要求

3． 当前开发人员技术水平

J2EE框架设计几个需要强调的观点

简单

可维护性

性能

开发效率

J2EE框架设计通用法则

1． 使用J2EE，而不是让J2EE牵着鼻子走（因需而用，而不是因有而用）

2． 万不得已不要使用EJB（谬论：把EJB视为J2EE核心）

3． 万不得已不要采用分布式架构

4． 企业应用不要仅仅局限于J2EE技术（业务知识，.NET技术）

5． J2EE不仅仅是一个规范

6． 谨慎处理数据库通用性，数据比J2EE应用的寿命更长

7． 利用好JDBC(SQL)技术

8． 不要忽略数据库的能力

9． 简单即是美

10．有时候使用EJB的好处可能来自于无状态Bean

11．在项目启动初期就应该考虑到性能问题

12．在设计的时候考虑应用在集群环境下运行的可能性

13．好的J2EE设计来自于好的OO设计

14．使用辅助类来隐藏底层API实现

15．在web UI层采用MVC框架

J2EE框架设计成则

1． 底层设计必须着眼当前可用规范而不是未来新规范

2． 没有针对实际需求的简单例程参考价值有限

3． 对框架进行详尽的测试

4． 对代码进行详尽注释

5． 尽可能早的对风险加以解决

6． 项目启动时就确定所采用的服务器

7． 在项目早期实现自动测试和构建

8． 在项目启动时雇佣J2EE设计专家

9． 避免重复发明轮子

10．统一设计和编码风格