mvc 架構(gòu)

　　這個很重要，非常重要。J2EE涵蓋的內(nèi)容大而全，但很多不一定就是具體實際項目需要的。象EJB級的權(quán)限控制，如果你的表現(xiàn)層（大部分項目就是Web server）和應用服務器不存在信任問題，那么基本上就不用考慮。又比如伸縮性，如果同時在線最多不超過100個，就沒什么用處。針對項目的實際情況選擇效費比最合適的解決方案，而不要為了應用先進技術(shù)而應用先進技術(shù)。

　　2、選擇合適的分布模型

　　提起分布，很多人可能都會有這樣的設(shè)想：server A處理認證，server B處理訂單，server C處理倉儲；如果B的負載太大，那么再細分一下：錄入、修改部分的EJB部署在server D，統(tǒng)計、分析部分的部署在server E，等等。其實沒有必要，我的體會是：除非業(yè)務必須（如分支機構(gòu)統(tǒng)一通過總部的app server來進行權(quán)限驗證），否則最好將所有的應用全部放在一個app server中，能在一個進程空間內(nèi)更好（使用home interface），然后進行平行的分布？D？D即集群中的所有app server功能上都是等價的。相比前一種垂直（或者網(wǎng)狀）分布，平行分布的可靠性、容錯能力、伸縮能力都要更好，同時減少了部署、管理負擔。最重要的是，減少了因為業(yè)務邏輯層內(nèi)部跨進程調(diào)用引起的開銷，提高了整體性能。然而，如果a、一些業(yè)務邏輯必須相互獨立部署、管理，b、負載較為集中地分布在若干個EJB中，那么，垂直分布還是必不可少的。

　　3、為Entity bean選擇合適的數(shù)據(jù)存儲方案

　　首先盡量使用CMP管理數(shù)據(jù)存儲，尤其是簡單的，大部分業(yè)務操作都是插入刪除修改的實體，不然光insert update就夠你忙的了，更不用說數(shù)據(jù)庫移植問題。其次對于簡單的一對一、一對多關(guān)系，如果你的app server沒有實現(xiàn)EJB2.0規(guī)范，可以考慮使用O/R映射工具幫助開發(fā)，象Cocobase， EJB creator等等，可以提高不少效率。對于復雜的對象存儲，沒辦法，老老實實寫代碼吧……

　　4、慎重考慮EJBHome.findByXXX（），listXXX（）的實現(xiàn)

　　設(shè)想對一個百萬記錄級的表進行檢索，結(jié)果集很可能是上萬條、十萬條，這本身就是一個耗費資源的過程；同時對于檢索到的每一個記錄還要做一次findByPrimarykey，這么多次跨進程調(diào)用，開銷可想而知。為什么有的人覺得用J2EE實現(xiàn)的程序奇慢無比，缺乏仔細的設(shè)計就是主要原因之一。

　　5、使用抽象數(shù)據(jù)結(jié)構(gòu)傳遞數(shù)據(jù)

　　例如，listOrder（）返回Collection而不是Vector，insertItems（）也是以Collection為參數(shù)而不是LinkedList.當然這個實際上與J2EE本身關(guān)系不是很大。

　　6、對Entity bean盡量使用Map來存儲、傳遞屬性

　　對業(yè)務流程沒有很大影響的屬性，象身高體重出生年月之類，最好用一個HashMap來存放，而不要直接用成員變量+getXXX/setXXX.對于ejbCreate也是一樣，十幾個參數(shù)的create方法，實現(xiàn)、維護都是代價高昂的。需知實際應用中這些字段的增減、屬性變化是家常便飯，光維護get/set方法可能就會讓你吐血了。但是，對于對業(yè)務流程有關(guān)建意義的字段，例如員工的入職日期決定其休假天數(shù)的計算，那么還是作為成員變量的好。

　　7、分清Entity bean和session bean的職責

　　Entity bean是實體的對象形式，它的職責應限于自身的存儲，以及對外部提供訪問內(nèi)部數(shù)據(jù)的接口（所以我認為它本質(zhì)上應該屬于數(shù)據(jù)存儲層）。Entity bean應該盡量避免自己實現(xiàn)有其他Entity bean參與的業(yè)務邏輯。例如，訂單的貨款收到以后，將訂單的狀態(tài)由“提交”變?yōu)椤吧А保瑫r將訂單的金額按照某種規(guī)則折算成該客戶的積分。這個業(yè)務流程有三個對象參與：客戶，訂單和積分折算策略。那么，實現(xiàn)流程的方法應該在哪個對象中呢，是客戶還是訂單？都不合適，如果在訂單中，那么訂單對象需要了解客戶積分屬性的接口及積分折算的接口；如果在客戶對象中也是一樣。耦合度增強就意味著維護難度增大，如果用戶對象的積分接口或者折算策略的接口改變了，那么改變就會蔓延到訂單對象中。合適的方式是用一個OrderProcessor來管理訂單處理流程，以stateless session bean來實現(xiàn)。OrderProcessor了解所有參與訂單處理的對象的接口，它集中管理對訂單的處理流程，如果流程發(fā)生變化，訂單生效之前要通過審批，這種變化不會影響到參與流程的實體對象；同樣，參與流程的某個對象接口發(fā)生了變化，也不會影響到其他對象。

　　8、重視表現(xiàn)層的復用

　　企業(yè)軟件的界面，大部分都可以用一些基本元素如grid， tree， page control， form等組合而來。如果能合理采用一些技術(shù)對這些元素進行復用，不但有利于降低開發(fā)成本，而且也便于統(tǒng)一維護界面風格。對J2EE的表現(xiàn)層，也就是JSP/servlet，可以采用的復用技術(shù)不多，基本上就是文件包含、創(chuàng)建類庫、Tag lig（本質(zhì)上還是創(chuàng)建類庫，使用起來我覺得還不一定有直接方法調(diào)用來的方便）等等。還有一些不同于JSP/servlet的表現(xiàn)層框架，如Apache Velocity、Enhydra、WebMacro等等，也可以參考。雖然Java還沒有一個規(guī)范的、統(tǒng)一的HTML界面元素類庫，但自己項目內(nèi)部統(tǒng)一使用某種方案還是可能的。

　　另外，XML+XSLT也是一種方案。將數(shù)據(jù)直接用XML形式表現(xiàn)出來，繞過Entity bean，然后再用XSLT模版轉(zhuǎn)化成最終界面。XML與XSLT之間屬于模式匹配式的松散耦合，可以避免強類型語言方法調(diào)用帶來的參數(shù)類型、個數(shù)、順序限制，做到徹底地數(shù)據(jù)與界面分離；同時XML形式的數(shù)據(jù)集在app server中可以按照合適的方案進行緩沖，避免頻繁訪問數(shù)據(jù)庫，抵銷XSLT轉(zhuǎn)換引入的性能負擔。同時XML和XSLT是業(yè)界廣泛采納的標準，如果今后采用不同的體系結(jié)構(gòu)（如從J2EE移植到。Net或者相反），表現(xiàn)層的XSLT形式的界面可以重用。JSP或ASP就沒有這種可能。問題在于首先要管理關(guān)系型數(shù)據(jù)到層次型XML數(shù)據(jù)的映射，其次如果沒有一個好的工具，創(chuàng)建、維護XSLT也是很費時費力的事情。我現(xiàn)在的項目正在朝這個方向努力，希望能做一個象Delphi那樣好用的，基于XSLT的HTML界面控件開發(fā)、管理、使用環(huán)境。

　　9、充分估計開發(fā)的艱辛程度

　　這個，一言難盡。總之實際需求的變化往往是超乎我們想象的，要在需求分析結(jié)束的時候就清晰劃分模塊接口幾乎做不到，計劃不如變化。而J2EE體系架構(gòu)是重量級的框架，雖然app server實現(xiàn)了很多功能，但同時也要求你開發(fā)的時候付出額外的代價。對于J2EE項目的資金、時間、人手等資源估計，寧可多不可少，千萬不要簡單認為用了一個weblogic就萬事大吉了。