1、認真考慮是否真要使用J2EE 

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

2、選擇合適的分布模型 

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

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

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

5、使用抽象數據結構傳遞數據 
例如，listOrder()返回Collection而不是Vector，insertItems()也是以Collection為參數而不是LinkedList。當然這個實際上與J2EE本身關系不是很大。 

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

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

8、重視表現層的復用 

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

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

9、充分估計開發的艱辛程度 

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