今天就跟大家聊聊有關(guān)如何實現(xiàn)J2EE分布式系統(tǒng)框架設計，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
框架設計（Framework Design）是系統(tǒng)設計的重要組成部分，一個設計優(yōu)秀的框架是一個可擴展和可改變（遷移）系統(tǒng)的基礎。下面針對常見J2EE分布式的信息系統(tǒng)（特別是B/S形式的系統(tǒng)），提出作者在框架設計上的觀點和思路。
目前應用J2EE技術(shù)構(gòu)建信息系統(tǒng)的需求越來越復雜，開發(fā)周期越來越緊迫，同時對系統(tǒng)的穩(wěn)定性、擴展性和可維護性要求也越來越高。那么如何滿足客戶對系統(tǒng)要求，加快我們的開發(fā)呢？信息系統(tǒng)需要一個持久化的存儲設備（如：數(shù)據(jù)庫）中存放和取回信息數(shù)據(jù)。當存儲設備改變時，我們?nèi)绾问瓜到y(tǒng)支持這個改變，而不用重寫我們的程序代碼呢？已有的代碼能不能在新的系統(tǒng)上重用呢？類似問題，給我們系統(tǒng)設計帶來很大的挑戰(zhàn)。
一個有效的解決方法是把信息業(yè)務信息按照應用功能模塊拆分開：業(yè)務邏輯與數(shù)據(jù)庫服務器分開，用戶界面與業(yè)務邏輯分開。辟此相對獨立，任一方任何改變都不會影響對方。這就是我們經(jīng)常提到的三層概念。
*表示層（Presentation）
*業(yè)務邏輯層（Business Logic）
*數(shù)據(jù)存儲層（Data）
表示層負責提供用戶界面，業(yè)務邏輯層負責實現(xiàn)業(yè)務邏輯，數(shù)據(jù)存儲層負責業(yè)務邏輯層中所有數(shù)據(jù)的持久的存儲。
業(yè)務邏輯層在三層模型中具有很好的伸縮性，設計者往往根據(jù)系統(tǒng)容量、分發(fā)、部署等等情況再一步把業(yè)務邏輯層細分，從而產(chǎn)生了多層。這就是所謂n層體系結(jié)構(gòu)。所以業(yè)務邏輯層也是我們系統(tǒng)設計中最重要的一塊。
引入三層模型后，我們就可以針對這三層的特點定義出一種可重用的、可擴展的類集合，它通過標準的API來先外提供服務。這些類集合的劃分和定義過程就是我們所要闡述的框架設計。
什么是框架（framework）？框架可以定義為一組關(guān)系服務的可擴展、可重用的子系統(tǒng)。常見的軟件框架有：MFC、VCL、JDK等等。其具有以下的特點。
*它是一個功能類的集合，類之間可以相互協(xié)作，為業(yè)務邏輯子系統(tǒng)提供服務。
*它包含了具體類和抽象類，這些類定義了標準的接口、對象間的交互作用和系統(tǒng)的相關(guān)常量。抽象類，可以包含抽象和具體的方法。
*為了利用、自定義或擴展框架的服務，通常需要框架的使用者去定義已存在的框架類的子類。
*框架中定義好的類只提供給用戶自定義的類調(diào)用，而從不調(diào)用用戶自己定義的類。
對于一個分布式信息系統(tǒng)，我們通過上面的討論，引入了三層的設計模型，現(xiàn)在就可以在這個模型上進行系統(tǒng)的框架設計了。但是，在開始設計之前先明確一下框架設計的目標。根據(jù)系統(tǒng)要求和框架定義，我們的目標為：
*類（組件、代碼）大化的重用。
*框架結(jié)構(gòu)盡可能合理、簡單和明了。
*框架要有靈活擴展性。滿足用戶的二次開發(fā)要求。
*框架要安全、穩(wěn)定、高效率，可維護，可升級。
*框架中子系統(tǒng)（包）之間不應該存在雙向性依存關(guān)系。
分布式信息系統(tǒng)三層設計模型中系統(tǒng)類的類型（Classes-Type）體系結(jié)構(gòu)圖如下所示：
圖（一）
所以此框架設計為：
把分布式信息系統(tǒng)的框架總體劃分為四個主體包，分別為：表示層的用戶界面包（ui），業(yè)務邏輯層的業(yè)務對象包（bs），數(shù)據(jù)持久層的數(shù)據(jù)持久包（ps），系統(tǒng)資源層的通用實用包（su），結(jié)合公司自己的命名規(guī)范，具體的UML框架圖可為如下所示：
圖（二）
其中，“ProjectName”為信息系統(tǒng)項目的立項英文命名，如：國有資產(chǎn)管理系統(tǒng)，“ProjectName”為“sams”；“CompanyName”為公司的英文簡稱，如：翱拓系統(tǒng)集成，“CompanyName”為“auto”。
“ui”----用戶界面包（User Interface）。
“bs”----業(yè)務邏輯包（Business Session）。
“ps”----數(shù)據(jù)持久存儲包（Persistence Store）。
“su”----系統(tǒng)通用實用包（System Utility）。
下面將結(jié)合J2EE體系結(jié)構(gòu)分別詳細討論各層包的框架實現(xiàn)問題。
通用系統(tǒng)資源層框架設計，從我們上面定義好框架來看就是系統(tǒng)通用包su（System Utility）的設計。從圖（二）可以看出，ui包、bs包和ps包都是從su包中調(diào)用接口，su包給它們提供服務。所以本層框架的設計是系統(tǒng)能否實現(xiàn)類（組件）重用的基礎，是系統(tǒng)能否滿足可靠穩(wěn)定、高效率和可維護的關(guān)鍵。
既然是通用包，那么它具體提供哪些服務（或工具）呢？我們知道J2EE體系結(jié)構(gòu)中也提供了許多標準的服務，如：JMS、EJB、JTA等等。那么su包是否也應該提供類似的服務呢？這些問題都沒有統(tǒng)一的答案，這主要看項目系統(tǒng)分析和設計人員根據(jù)項目本身的特點和需求，應用什么樣的技術(shù)和解決問題所運用什么樣的設計思想和設計模式等因素有關(guān)。
值得一提的是，“框架是骨架，設計模式是肉”。設計模式思想影響框架的構(gòu)成，一個框架中應用合適的設計模式來實現(xiàn)，才是框架精華的所在。在這一層，常應用到的設計模式有：結(jié)構(gòu)型的Bridge模式、Facade、Proxy；創(chuàng)建型的Factory、Singleton和行為型的Strategy等。
根據(jù)作者的經(jīng)驗，結(jié)合J2EE體系結(jié)構(gòu)的應用，通用系統(tǒng)資源層的框架可為：
圖（三）
圖（三）說明如下：
su包包含8個子包，分別為：
（1），resource包，包含標準接口訪問J2EE中間件（應用服務器）資源的類。如：容器的JNDI服務等等。
（2），factory包，包含創(chuàng)建不同類型對象的接口的類，目的是有利于控制類創(chuàng)建，減少一些關(guān)鍵對象誤用的風險。
（3），jms包，包裝了有關(guān)應用J2EE消息服務的類。
（4），ui包，針對表示層封裝一些標準通用的類。
（5），ejb包，引用Bridge設計模式，在EJB中加多一層封裝，一般以后方便擴展和維護EJB，減少ejb編程的風險。根據(jù)ejb的類型，分session和entity兩個子包。
（6），db包，包含有關(guān)訪問數(shù)據(jù)庫的類，包括：數(shù)據(jù)庫連接池、報表和序列號等標準接口。
（7），log包，包含記錄體統(tǒng)日志和調(diào)試應用的接口類。細分applog和appdebug兩個包。
（8），exception包，根據(jù)系統(tǒng)的特性，自定義一套應用異常。
（9）tools包，包含了常用標準的系統(tǒng)函數(shù)類。根據(jù)這些函數(shù)的類型，分為：date、maths、format和constfunc四個包。
以上框架僅為參考，設計人員可根據(jù)自己的實際需要，來重新定義。
表示層框架設計對應著我們定義的ui包框架設計。在針對J2EE體系結(jié)構(gòu)做系統(tǒng)設計時，往往應用MVC（Model-View-Controller）設計模式來實現(xiàn)。MVC模式根據(jù)應用的角色對應用進行分解，然后使用不同的方法解決。
*Model，模型，系統(tǒng)應用的具體數(shù)據(jù)模型，不關(guān)心怎么表示和何時訪問。只考慮數(shù)據(jù)的完整性和存儲方式。與數(shù)據(jù)持久層對應，所以是我們數(shù)據(jù)持久層框架設計所關(guān)心的問題。
*View，視圖，只關(guān)系如何表示的問題。本層討論。
*Controller，控制器，控制器是解決何時訪問的問題。是系統(tǒng)應用的業(yè)務邏輯，確定是否滿足一定條件時，應用程序才能訪問模型（Model）中的特定數(shù)據(jù)，然后根據(jù)情況把取得的具體數(shù)據(jù)委托給負責表示的視圖（View）。與業(yè)務邏輯層對應，在業(yè)務邏輯層框架設計中討論。
在J2EE體系中，AWT、SWING、JSP和Servlet都是針對表示（視圖）而設計的。在實際應用中，我們經(jīng)常根據(jù)系統(tǒng)不同的功能模塊寫JSP和APP客戶端應用程序來和用戶交互，所以在框架定義中可分為兩個包，jsp包和app包；同時，有時候還需要定義一些系統(tǒng)常量和處理一些頁面邏輯，所以我們也定義一個vbn（view bean）包來存放這些頁面類和常量類。所以表示層的框架設計可為：
圖（四）
圖（四）說明如下：
（1）jsp包，按信息系統(tǒng)不同的功能模塊存放jsp程序文件。由于jsp文件類型不是java文件類型，所以此包可以當作目錄處理，把其提出來，按照系統(tǒng)部署的要求，單獨放在一個合理的目錄下。其中JFunctionModule1、JfunctionModule2、JfunctionModule3等名稱為信息系統(tǒng)具體的功能模塊名稱?？筛鶕?jù)需要來定義和安排目錄。
（2）app包，存放java客戶端應用程序。其中AFunctionModule1、AfunctionModule2、AfunctionModule3等包名稱為信息系統(tǒng)具體的功能模塊包名稱。根據(jù)客戶端應用程序的所屬關(guān)系，存放到具體的功能模塊包中。
（3）vbn包，存放信息系統(tǒng)表示層的常量定義類和頁面處理類。
最后，值得一提的是：在表示層的jsp頁面開發(fā)中，為了避免把太多的代碼和邏輯編寫在同一個頁碼中，提高jsp程序的效率和可維護性，可以應用VC（View-Controller）設計模式，html為視圖，servlet為控制器。當然還可以應用struts技術(shù)來實現(xiàn)，這里就不在討論了。這應該屬于具體的程序設計問題。
業(yè)務邏輯層設計對應我們定義bs包的框架設計。是MVC模式的Controller（控制器），負責訪問數(shù)據(jù)持久層，把返回數(shù)據(jù)提交給表示層，起到承上啟下的作用。J2EE體系結(jié)構(gòu)中，我們一般應用會話Bean來實現(xiàn)。
業(yè)務邏輯層設計在系統(tǒng)設計的詳細設計中是最為復雜，工作量對大的一塊。需要從系統(tǒng)分析中提取信息系統(tǒng)各個功能模塊的用例（Use Case），再針對每個用例，應用UML語言詳細繪畫出此用例的順序圖（或協(xié)作圖），然后根據(jù)實際情況決定是否使用有狀態(tài)還是無狀態(tài)的會話Bean。但是，此層的的框架設計卻簡單明了，其框架可為：
圖（五）
在bs包下直接根據(jù)信息系統(tǒng)的功能模塊的名稱來定義子包。其中，bsFunctionModule為功能模塊的英文名稱。
數(shù)據(jù)持久層對應MVC設計模型中的Model，其設計是信息系統(tǒng)設計的最重要部分，是系統(tǒng)的性能和是否可平移的基礎，其設計好壞直接影響到項目的成功與否。數(shù)據(jù)持久層框架設計只有詳細討論數(shù)據(jù)模型設計后，才能比較好勾畫出來。故本節(jié)準備探討持久數(shù)據(jù)模型設計后，再實現(xiàn)其框架設計。
◆常見數(shù)據(jù)持久層設計類型
（A）在業(yè)務邏輯層的類中，直接使用SQL代碼。如下圖所示：
圖（六）
*優(yōu)點：
寫代碼的效率很高。
*缺點：
SQL代碼到處出現(xiàn)在程序的類中；邏輯業(yè)務類與數(shù)據(jù)庫直接耦合在一起，這意味著任何小的改動都導致程序原代碼的修改。
*結(jié)論：
對于小型應用程序是可行的，對于企業(yè)級的系統(tǒng)，這種在邏輯業(yè)務類中寫死SQL的方法，會導致代碼難于維護和擴展。
（B）SQL代碼封裝在一個或多個數(shù)據(jù)代理類中。如下圖所示：
圖（七）
*優(yōu)點：
在業(yè)務類和數(shù)據(jù)庫之間加多一層封裝，是系統(tǒng)的可維護性大為提高。這種方法包括可以利用數(shù)據(jù)庫存儲過程、SQLJ以及微軟ADO數(shù)據(jù)訪問的策略。
*缺點：
對數(shù)據(jù)庫進行任何一點的改動都會直接影響到數(shù)據(jù)代理的代碼，也就是程序原代碼還必須改動。
（C）不用寫SQL代碼，對數(shù)據(jù)庫的訪問完全通過具有魯棒性數(shù)據(jù)持久層來實現(xiàn)。如圖所示：
圖（八）
所謂的魯棒性數(shù)據(jù)持久層至少要滿足下面的條件：
（1），支持關(guān)系數(shù)據(jù)庫的高級的特性。（如：事務、存儲過程、游標）
（2），支持對象和關(guān)系之間的映射，用戶不直接用SQL與數(shù)據(jù)庫交互。
（3），支持多連接，支持數(shù)據(jù)庫連接池。
（4），支持多種體系結(jié)構(gòu)，支持不同廠商的數(shù)據(jù)庫。
*優(yōu)點：
應用程序開發(fā)人員不需要了解數(shù)據(jù)庫結(jié)構(gòu)，甚至也沒必要知道對象如何保存在數(shù)據(jù)庫的。有利于組織開發(fā)大規(guī)模的針對關(guān)鍵業(yè)務的信息系統(tǒng)。系統(tǒng)的遷植性、可維護性和擴展性好。
*缺點：
由于對數(shù)據(jù)庫的訪問交給了持久層處理，理論上對系統(tǒng)的性能上有些影響。
◆具體選型
上面列出了常見的數(shù)據(jù)持久層的幾種類型，那么我們究竟應用那種類型比較合適呢？這需要根據(jù)系統(tǒng)規(guī)模和需要的具體情況來決定。在J2EE體系結(jié)構(gòu)中開發(fā)系統(tǒng)，我們應該選擇（B）和（C）兩種數(shù)據(jù)持久層比較合適。
在J2EE體系結(jié)構(gòu)中，類型（C）魯棒性數(shù)據(jù)持久層可以應用EJB的容器管理實體Bean（CMP）來實現(xiàn)，在EJB2.X中CMP就是為了實現(xiàn)魯棒性數(shù)據(jù)持久層而制定的標準規(guī)范。開發(fā)人員不必在CMP中編寫SQL代碼，一切和數(shù)據(jù)庫的交互都交給EJB容器去負責。由于J2EE是開放、標準規(guī)范，所以，CMP組件可以在EJB容器與數(shù)據(jù)庫之間移植。
在實際的信息系統(tǒng)開發(fā)過程中，我們往往需要處理一些復雜的查詢或報表，而這些查詢數(shù)據(jù)往往來源于多個數(shù)據(jù)表，而且其查詢結(jié)果的實體對象的觀念性不強。這個時候，我們用CMP去封裝它就顯得有點無能為力了。因為理論上實體Bean畢竟代表了數(shù)據(jù)庫表里面的一行數(shù)據(jù)。
遇到這種情形，數(shù)據(jù)持久層的設計采用類型（B）就比較合適了。我們可以用EJB的無狀態(tài)會話Bean來實現(xiàn)這層的封裝。通常的利用Bridge設計模式來實現(xiàn)：
（1）建立數(shù)據(jù)訪問對象DAO（Data Access Object）接口。定義數(shù)據(jù)源的抽象操作行為，提供方便訪問和維護數(shù)據(jù)的標準API結(jié)構(gòu)。
（2）實現(xiàn)數(shù)據(jù)訪問對象接口。DAOImplementor。實現(xiàn)具體DAO接口的內(nèi)容，根據(jù)應用的數(shù)據(jù)源類型不同，可以有針對多個數(shù)據(jù)源的實現(xiàn)（如：DAOImplementorSQLServer，DAOImplentorOracle等等）。然后應用Adapter設計模式，將特定的數(shù)據(jù)源驅(qū)動接口分配到DAO中去。
（3）建立EJB調(diào)用DAOImplementor，實現(xiàn)業(yè)務邏輯。
如下圖所示：
圖（九）
◆框架設計
通過，上面的討論，我們數(shù)據(jù)持久層（ps）包的框架可為：
圖（十）
ps包下按信息系統(tǒng)的功能模塊來劃分子包（如：上圖分了3個功能模塊包，PfunctionModule1、PfunctionModule2和PfunctionModule3），每個功能模塊包再分：
be（business entity）包，包含業(yè)務實體對象（數(shù)據(jù)庫關(guān)系映射對象），DAO定義接口等等。
eb（entity bean）包，包含實現(xiàn)數(shù)據(jù)持久層的實體組件。
sb（session bean）包，包含實現(xiàn)數(shù)據(jù)持久層的會話組件。
系統(tǒng)框架設計不是一成不變的，往往根據(jù)系統(tǒng)設計師的對某個信息系統(tǒng)的見解不同，框架也有所差別。但是要設計一個好的框架，除了有明確的設計目標外，關(guān)鍵在于：需要調(diào)查和研究系統(tǒng)同類產(chǎn)品的狀況及相關(guān)的技術(shù)特點，了解目前流行技術(shù)對此產(chǎn)品所能提供理論和技術(shù)支持情況，結(jié)合自己產(chǎn)品的特點，才能逐步勾畫出整個產(chǎn)品項目的框架藍圖。
看完上述內(nèi)容，你們對如何實現(xiàn)J2EE分布式系統(tǒng)框架設計有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道，感謝大家的支持。
重慶分公司
重慶分公司
