設(shè)計目標(biāo)：

1.       開發(fā)效率

2.       性能,、預(yù)算

3.       符合OO設(shè)計

4.       避免復(fù)雜性

5.       可維護(hù)性、可擴(kuò)展性,，可重用性

分布式應(yīng)用

不足：

1．  增加了應(yīng)用的復(fù)雜性

2．  對性能會造成一定的影響

3．  給OO Design帶來一定的困難

優(yōu)點(diǎn)：

1．  能滿足多類型客戶端的需求（applet, swing）

2．  能同時將組件部署到不同的應(yīng)用服務(wù)器

采用前提：

1．  客戶端需要使用J2EE技術(shù),，比如Swing

2．  為了與已有的分布式應(yīng)用集成

3．  需要將J2EE組件部署到多個應(yīng)用服務(wù)器

4．  實現(xiàn)對多應(yīng)用組件部署進(jìn)行控制，提高系統(tǒng)靈活性,、可靠性

可選技術(shù)：

可通過集群和負(fù)載平衡（remote interface調(diào)用單服務(wù)器應(yīng)用）來實現(xiàn)分布式應(yīng)用的健壯性,、靈活性

EJB技術(shù)

缺點(diǎn)：

1．  測試?yán)щy

2．  部署麻煩（classloader復(fù)雜、部署描述符復(fù)雜,、開發(fā)－部署－測試周期長）

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

4．  技術(shù)復(fù)雜,，可能將簡單需求變得復(fù)雜開發(fā)

5．  減少了應(yīng)用服務(wù)器的選擇

優(yōu)點(diǎn)：

1．  能遠(yuǎn)程訪問組件

2．  能將應(yīng)用組件部署到不同服務(wù)器（分布式應(yīng)用）

3．  支持多客戶端訪問

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

5．  能實現(xiàn)復(fù)雜的事務(wù)管理

采用前提：

1、  對EJB底層比較熟悉

2,、  需要使用EJB的角色安全訪問

3,、  需要使用EJB的事務(wù)管理

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

5,、  需要使用基于RMI/IIOP的分布式架構(gòu)

4種J2EE基本框架

一．非分布式框架

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

實現(xiàn)簡單,、能滿足大部分需求,，是中小型J2EE項目中采用最多的框架，雖然沒有使用EJB,，但是層次清晰,。

優(yōu)點(diǎn)：

1．簡單

2．速度快

3．符合OO設(shè)計

4．容易測試

缺點(diǎn)：

1．僅僅適用于Web UI

2．自己管理事務(wù)

3．無法實現(xiàn)高并發(fā)處理

4．無法使用entity bean

5．不支持多JVM應(yīng)用

2、Web UI + local EJB + DBMS

稍微復(fù)雜,，能使用EJB容器的事務(wù),，線程管理，沒有采用分布式特性,，性能比遠(yuǎn)程調(diào)用稍好

優(yōu)點(diǎn)：

1．降低了EJB的復(fù)雜度

2．不會對基礎(chǔ)框架造成影響

3．本地調(diào)用對性能有一定優(yōu)勢

4．可以使用EJB容器的事務(wù)和線程管理

5．可以使用entity bean

缺點(diǎn)：

1．比純web應(yīng)用復(fù)雜

2．單JVM運(yùn)行

3．單客戶端（web）支持

4．測試?yán)щy

二．分布式框架

1．基于遠(yuǎn)程調(diào)用的分布式

架構(gòu)最復(fù)雜,，對有遠(yuǎn)程訪問客戶端的需求是理想選擇，健壯,、靈活,，但是不容易維護(hù)、測試,、實現(xiàn)困難

優(yōu)點(diǎn)：

1．  多客戶端支持

2．  可將應(yīng)用組件部署到多臺服務(wù)器（JVM）

缺點(diǎn)：

1．增加了復(fù)雜度

2．影響性能

3．調(diào)試?yán)щy

4．必須在EJB容器中運(yùn)行

5．異常處理復(fù)雜

6．OO設(shè)計困難

2．基于Web Service的分布式

對非J2EE客戶端調(diào)用適用性好,，無分布式調(diào)用，往往作為第一,、第二架構(gòu)的變體,。

優(yōu)點(diǎn)：

1．  通用標(biāo)準(zhǔn)，能支持更多客戶端類型

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

3．  Web service傳輸協(xié)議比RMI更友好

缺點(diǎn)：

1．  性能差

2．  需要作object與xml之間的轉(zhuǎn)換

3．  相對于java client來說,，性能也不好

UI框架部分

選擇UI的幾個決定性因素：

1．  用戶的實際需求

2．  項目的性能要求

3．  當(dāng)前開發(fā)人員技術(shù)水平

J2EE框架設(shè)計幾個需要強(qiáng)調(diào)的觀點(diǎn)

簡單

可維護(hù)性

性能

開發(fā)效率

J2EE框架設(shè)計通用法則

1．  使用J2EE,，而不是讓J2EE牽著鼻子走（因需而用，而不是因有而用）

2．  萬不得已不要使用EJB（謬論：把EJB視為J2EE核心）

3．  萬不得已不要采用分布式架構(gòu)

4．  企業(yè)應(yīng)用不要僅僅局限于J2EE技術(shù)（業(yè)務(wù)知識，.NET技術(shù)）

5．  J2EE不僅僅是一個規(guī)范

6．  謹(jǐn)慎處理數(shù)據(jù)庫通用性,，數(shù)據(jù)比J2EE應(yīng)用的壽命更長

7．  利用好JDBC(SQL)技術(shù)

8．  不要忽略數(shù)據(jù)庫的能力

9．  簡單即是美

10．有時候使用EJB的好處可能來自于無狀態(tài)Bean

11．在項目啟動初期就應(yīng)該考慮到性能問題

12．在設(shè)計的時候考慮應(yīng)用在集群環(huán)境下運(yùn)行的可能性

13．好的J2EE設(shè)計來自于好的OO設(shè)計

14．使用輔助類來隱藏底層API實現(xiàn)

15．在web UI層采用MVC框架

J2EE框架設(shè)計成則

1．  底層設(shè)計必須著眼當(dāng)前可用規(guī)范而不是未來新規(guī)范

2．  沒有針對實際需求的簡單例程參考價值有限

3．  對框架進(jìn)行詳盡的測試

4．  對代碼進(jìn)行詳盡注釋

5．  盡可能早的對風(fēng)險加以解決

6．  項目啟動時就確定所采用的服務(wù)器

7．  在項目早期實現(xiàn)自動測試和構(gòu)建

8．  在項目啟動時雇傭J2EE設(shè)計專家

9．  避免重復(fù)發(fā)明輪子

10．統(tǒng)一設(shè)計和編碼風(fēng)格

本文來自CSDN博客,，轉(zhuǎn)載請標(biāo)明出處：http://blog.csdn.net/Peter_K/archive/2007/03/02/1519495.aspx