1、認真考慮是否真要使用J2EE（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就萬事大吉了。
