在 J2EE 架構中，實體組件僅是 EJB 層的實現選項之一，絕不應直接暴露給客戶端或 Web 層。所有外部訪問必須通過會話組件（Session Bean）這一業務邏輯層進行。這種分層設計不僅保持了架構的靈活性，往往還能顯著提升系統性能，避免了遠程接口的頻繁調用開銷。
會話組件應通過標準的 Java 數據存取接口（DAO）來訪問實體組件，而非直接依賴實體組件的特定 API。引入持久化門面模式，能有效隔離業務邏輯與底層持久化技術。即便初期採用 Entity Bean，未來也能平滑遷移至 JDO、Hibernate 或其他 ORM 框架，實現持久化策略的熱插拔。
實體組件本質上是將非面向對象的數據存儲（如關係型數據庫）對象化的薄層適配器。若底層採用 ODBMS 等面向對象數據庫，這層封裝反而顯得多餘，可直接通過輔助類從會話組件訪問數據存儲。
關於實體組件的兩大核心爭議在於：粒度選擇與是否承載業務邏輯。
結論：在 EJB 2.0 環境下，建議採用 CMP 實現細粒度實體組件。
無論任何理由，嚴禁在實體組件中編寫業務邏輯。實體組件的職責單一且明確：負責數據的持久化與加載，業務規則應完全下沉至會話組件層。
BMP（Bean Managed Persistence）的 find 方法存在嚴重性能缺陷。查詢 5000 條記錄時，BMP 會執行 1 次主鍵查詢 + 5000 次逐條加載查詢，共 5001 次數據庫交互。正確做法應為單條 IN 查詢獲取所有數據。
建議：棄用 BMP，改用無狀態會話組件配合 DAO 層直接執行 JDBC/JPA 操作。BMP 增加了複雜度卻未帶來實質價值。
CMP 2.0 引入 Home 業務方法（Home Method）與實體組件業務方法，均可通過 ejbSelect() 執行複雜查詢、調用存儲過程等操作，極大擴展了聲明式持久化能力。
嚴守分層邊界，方能構建高內聚、低耦合、可演進的 J2EE 企業級應用。
