1，實體組件只是EJB層中的實現選擇之一。實體組件不應該被暴露給客戶軟件。WEB層和其他EJB客戶軟件絕不應該直接訪問實體組件。它億只應該與由實現應用業務邏輯的會話組件所構成的一個會話組件層打交道。這不僅保持了應用設計與實現中的靈活性，而且常常還改進了性能。
2，會話組件最好只通過普通JAVA數據存取接口的一個持久性門面來訪問實體組件。雖然實體組件衽了一種特殊的數據處理方法，但標准Java接口卻沒有。這種方法不公保持了靈活性，而且還預見性地檢驗了一個應用。筆者對實體組件的未來產生了極大的懷疑，因為凡是在實體組件適用的任何地方，JDO都能提供一個更簡單、更通用、性能更高的解決方案。通過使用DAO，我們仍有換用JDO或其他任一持久性策略的能力，即便在一開始就使用實體組件實現了一個應用之後。
3，實體組件通常是一 個薄層，用於具體化一個不是基於對象的數據存儲器。如果使用一個像ODBMS之類的面對對象的數據存儲器，這個薄層不是必需的，因為可以使用助手類從會話組件中訪問這種數據存儲器
4，關於實體組件的爭論有兩點：一）實體組件的粒度，二）實體組件是否可以實現業務邏輯。
5，一個粗實體可能會建模一條邏輯記錄，而這條記錄會分布於多個表中；而一個精細粒度可能會映射到單個表中；在EJB2.0 CMP中通常認為精細粒度會更加方便,雖然粗粒度的建模更利於面向對象的設計，但有一個結論就是：
在EJB2.0中，最好是通過使用CMP把實體組件用於相當精細的對象。
6,無論任何理由都不能破壞以下約定：
在實體組件中只實現持久性邏輯，不要實現業務邏輯！
7，BMP的“N+1”問題，對於BMP的find方法，它在EJB中的實現需要返回主鍵集合，在幕後BMP做了什麼了？
如你要選取某個城市的全部人員信息，那麼BMP會執行n+1次類這樣的查詢(n代表將要找到的記錄)
SELECT PK,NAME, FROM USERS WHERE PK=
...
SELECT PK,NAME, FROM USERS WHERE PK=
如果你要查的數量少就還好，不幸的是如果你查詢的記錄比較多，如5000，這對於一個擁300萬用戶的系統來講應該是很正常的查詢，那麼BMP會去自動執行5001次類似的查詢。而任何正當的實現方法應該是類似以下的語句：
SELECT PK,NAME, FROM USERS WHERE PK IN
結論：不要實體組件中使用BMP，而要從無狀態會話組件中使用持久性。和從一個DAO層中執行數據存取相比，使用BMP不會增加什麼價值，只會增加復雜性。
8，CMP2.0引進了主業務方法（我平時叫home方法)，每個實體有自己的業務方法（遠程接口中定義的方法）；兩者均可以通過調用ejbSelect()方法來獲取想要進行的邏輯操作，當然也可以作任何其它操作，如調用存儲過程等。
9,應該使用DAO來分離數據數據存取與業務邏輯。當然DAO中是可以用無狀態會話BEAN來實現的。
