在具體的實現中，表現層可爲Struts/JSF等，業務層、訪問層可爲JavaBean或EJB等，資源層一般爲數據庫。
宏觀上的層次就是這樣，在具體現實中，有如下幾種實現形式：
1， 輕量級實現
表現層使用基於MVC的框架，比如Struts或JSF
業務層使用JavaBean（就是常說的Service）
訪問層使用JavaBean（就是常說的DAO）
優點：
輕量級實現，簡單明瞭ü
缺點：
難以無法實現分佈式應用ü
以下功能必須通過編程實現ü
事務控制²
資源管理（包括組件的創建）²
線程安全問題²
安全性²
2， 重量級J2EE實現
表現層依然是基於MVC的框架
訪問層採用實體Bean實現，如果可能最好採用CMP，實現起來更簡潔。此處的實體Bean可以考慮採用本地接口
業務層一分爲二，服務控制器可以由會話Bean充當，用來封裝業務流程（相當於輕量級實現中的Service），也可以考慮採用本地接口；門面也可以由會話Bean充當（一般來說無狀態會話Bean足矣），作爲業務層的入口，應該採用遠程接口。
優點：
以下功能可由EJB容器自動實現，或通過配置實現ü
事務控制²
遠程訪問²
線程安全²
資源管理²
安全性²
可以進行分佈式應用ü
因爲採用了EJB，故部分特徵可以由裝配人員來配置（比如事務，安全性等），不需要在軟件中硬編碼ü
EJB組件有更好的重用性ü
可利用容器提供的其他企業級的功能（比如集羣，容錯，災難恢復等）ü
可以加入MDB（實現異步通訊）等技術ü
缺點：
開發難度較高ü
如果不恰當的使用實體Bean，會造成效率低下。如果採用CMP，則很多數據訪問的操作不能直接實現。ü
缺少良好的開發環境ü
軟件可能依賴於具體的EJB容器ü
EJB容器可能很貴，開發軟件也可能很貴ü
3， 輕量級和重量級J2EE的切換
如果項目有需求，並有充分的時間，還可以通過在表現層和業務層的交界處加入“業務代表”（JavaBean + 服務定位器實現）來對錶現層隱藏對業務層訪問的細節(JavaBean和EJB的訪問方式顯然不同)，只需替換“業務代表”就可以切換輕量級和重量級兩種實現。舉例說明，一般電話上都有一個P/T開關（脈衝/音頻開關），隨着開關狀態的不同，撥號時電話機會判斷是使用脈衝撥號還是音頻撥號。
這種架構唯一的缺點就是必須寫兩套實現代碼……
4， 輕量級J2EE實現
訪問層通過JavaBean調用ORM框架實現（Hibernate，iBatis等），代碼簡潔，功能完備（相對於EJB 2.x而言），如果用的是Hibernate，可以忽略底層數據庫的差異，如果用的是iBatis，則方便對SQL進行優化。
業務層和訪問層依靠AOP框架（如Spring）可以在切面中實現事務，安全性等功能，同時不影響業務代碼。如果採用Spring，其中已經內置了事物切面，並可以輕易的與主流ORM框架進行整合，實現聲明式的事物管理。當然，更可以使用IoC模式降低組件間的耦合性。
優點：
可以通過AOP框架實現事物、安全性等功能，同時不影響業務代碼²
ORM框架比CMP更靈活，比BMP更簡潔（相對於EJB² 2.x而言），運行效率也比較高
如果使用Spring，可以用更簡單的方式實現J2EE中比較複雜的功能²
無需額外的容器²
ORM和AOP框架可以找到免費的開源實現，降低項目成本（不過也有人認爲採用開源項目可能綜合成本更高）²
缺點：
非官方框架，缺少文檔、技術支持和業界經驗²
採用技術太多，學習曲線較高，難以招到合適的程序員（咱們學員可以考慮在這方面下點功夫，呵呵）²
某些企業級的功能輕量級框架還不能實現（或獨立實現）²-----------------------------------------
測試、調試均比較複雜²
另類之處：
使用BMP + Hibernate（具體做法爲BMP中的持久化方法，比如ejbLoad, ejbStore等都委託給Hibernate實現）
優點：
藉助於Hibernate強大的ORM功能彌補CMP的不足（特別是EJB-QL）
缺點：
事物不好控制
不倫不類，容易發生未知的錯誤（比如Hibernate自身的緩存可能會於容易提供的緩存衝突）
另類之處：
將業務層（也可能包含訪問層）包裝成Web Services，支持遠程調用
優點：
藉助於Web Services可以實現鬆散耦合分佈式應用，說的大一點，就是傳說中的SOA，呵呵
缺點：
Web Services自身效率不高，無狀態，安全性差
當然，即使不分層，也能做出軟件來，但我們應該思考怎麼做才能最好？如果說分層不好，那麼不分層的優勢又在哪裏呢？？如果說分層有性能的損耗，那麼性能損耗在哪裏呢？？如果不分層，軟件工程思想中的“分而治之”的原則啓不受到了質疑？
有人說，分層是爲了減少代碼量，如果分層是爲了減少代碼量，那怎麼能減少，代碼的重用也許會減少一些，但是程序更多的是業務，我們關心的也只是業務，試問分層的意義就是爲了減少代碼量？
總之我的觀點就是：軟件分層是必須做的。至於框架，不應該問用不用，而應該問用什麼？要選用實踐檢驗過的框架，畢竟實踐是檢驗真理的唯一標準。
宏觀上講，我們採用了分層的架構，將軟件分爲如下的層次：
