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

　　2、選擇合適的分布模型

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

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

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

　　5、使用抽象數(shù)據(jù)結(jié)構(gòu)傳遞數(shù)據(jù)
　　 例如，listOrder()返回Collection而不是Vector，insertItems()也是以Collection為參數(shù)而不是LinkedList。當(dāng)然這個(gè)實(shí)際上與J2EE本身關(guān)系不是很大。

　　6、對Entity bean盡量使用Map來存儲、傳遞屬性
　　 對業(yè)務(wù)流程沒有很大影響的屬性，象身高體重出生年月之類，最好用一個(gè)HashMap來存放，而不要直接用成員變量+getXXX/setXXX。對于ejbCreate也是一樣，十幾個(gè)參數(shù)的create方法，實(shí)現(xiàn)、維護(hù)都是代價(jià)高昂的。需知實(shí)際應(yīng)用中這些字段的增減、屬性變化是家常便飯，光維護(hù)get/set方法可能就會讓你吐血了。但是，對于對業(yè)務(wù)流程有關(guān)建意義的字段，例如員工的入職日期決定其休假天數(shù)的計(jì)算，那么還是作為成員變量的好。
　　 推薦一個(gè)關(guān)于EJB設(shè)計(jì)模式的好地方：
　　 http://www.theserverside.com/resources/patterns_review.jsp


　　7、分清Entity bean和session bean的職責(zé)

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

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

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

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

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

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