最近參與了一個嚴重依賴EJB技術，針對某特定領域的軟件產品。由於該領域的業務邏輯種類復雜繁多，UI層無法做到非常簡單，同時數據的采集、提交和表現也非常復雜，因此該產品使用了CS架構，通過一個胖客戶端連接EJB中的業務邏輯接口，然後由EJB負責調用下層的DAO等完成處理過程。
由於EJB本身就是重量級的侵入型框架，在一定程度上阻礙了面向對象設計，同時開發人員對EJB接口功能劃分的問題也並沒有足夠重視，只是本著“先運行再重構”的簡單想法進行了接口功能粒度的劃分。
在開發初期中，因為涉及到的業務量較小，因此基本上若客戶端需要某個功能，EJB層肯定有相應的功能接口及其實現。換而言之，EJB層本身就不是面向對象的，所有的功能都零散地分布在各個EJB中。例如一個叫做Customer的EJB提供了客戶購買產品、退貨、更換等邏輯的實現，一個叫做Product的EJB提供了產品定義、價格定義等邏輯的實現。
當軟件開發進行到後期的時候，由於業務量越來越大，各個EJB也變得越來越臃腫與龐大，一個EJB裡面常常塞滿了看起來差不多，但又不完全一致的方法――整個EJB層成為一個包羅反象、無所不能卻又混亂不堪的怪物。
幸好，由於有完備的文檔支持，整個項目沒有失控，各個EJB雖然越來越大，越來越“面向過程”，但整體的功能實現還是得到了保證。最終項目驗收的時候，雖然整個軟件不“很好看”，但也在功能、速度和成本方面達到了基本要求。
漫長的維護期開始了……
經過這次不能說成功或失敗的開發經歷後，我有了一點想法：
1.使用EJB這種侵入型框架時，一定要先對業務進行細分，將各個大功能項劃分開。
2.在功能細分的基礎上，建立相應的業務對象模型，每個業務對象負責一類事務的處理。例如上文中的CustomerBean類其實應該作為一個獨立的業務對象存在，而不是作為一個被隨意調用的EJB存在。
3.客戶端調用EJB時，不是對具體功能的調用，而是通過轉發的方式，對業務對象進行調用。客戶端只是簡單的將參數傳遞給EJB，然後由EJB負責業務對象的初始化（或以其他形式得到業務對象），然後將參數傳遞給業務對象，生成結果後再返回給客戶端。EJB在這裡只是起轉發的作用。
這樣做可以解決EJB層責任混亂的問題。
在以前的設計中，EJB層負責對傳入數據的解釋，然後調用所有的業務邏輯，最後對生成結果進行包裝，返回給客戶端。而且整個過程由於是采用硬編碼的形式寫在了一個函數中，因此重用的可能性不大。
在新的設計中，由於一次客戶端操作經常是由多次原子型操作（從業務層面看）組成的，因此可以把這些業務流程的控制邏輯放在EJB層中，並負責對客戶端傳入結果的解釋以及對返回給客戶端的結果進行包裝。因此，EJB層相當於是一個解釋器＋業務邏輯組織者的角色，它將業務邏輯的實現推遲到了各個業務對象中來實現，同時有利於各個業務對象中業務邏輯的重用。
