J2EE設計模式學習筆記之--用實體組件進行資料存取

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來實現的。
未完待續