在一個後台使用關系數據庫（數據庫培訓 數據庫認證 ）的ejb系統中，如果客戶端只需要使用表格形式的用戶界面來顯示數據，那麼怎樣才能高效的存取，表格化服務器端的數據呢？
在分布式計算中，一個最常用的用例就是為客戶端顯示服務器端的靜態數據，這些數據通常是只讀的，在客戶端很少要更新。舉個例子：一個應用程序要顯示大批量的數據到客戶端，這些數據是只讀的，在Html表格中顯示可能如下：
－－－－－－－－－－－－－－－
Employee | Department
------------------------------
Adam Berman | Development
Ed Roman | Management
Clay Roach | Architecture
------------------------------
在服務器端，我們會將數據模型化為一個Employee實體Bean和一個Department實體Bean.具體過程如下：在session Facade模式下調用getEmployees()方法。這需要先在home接口上調用finder方法，返回所有的employee,對每個employee查找其對應的Department Entity Bean.然後利用這兩個實體Bean獲取的數據，創建一個數值對象視圖，session bean將此數值對象的雇員/部門集合返回到客戶端：
public class EmployeeProjectVIEwObject {
public String employeeName;
public String employeeTitle;
...
public String departmentName;
public String departmentLocation;
...
}
根據不同的ejb server和應用程序，這個過程會存在很多問題：
1)n+1次 Entity Bean的數據庫調用問題
意思是：對BMP和某些CMP,從N個entity Beans中獲取數據會需要n＋1的數據庫調用，對一個好的CMP實現來說，應該允許批量加載，而一個開發者應知道這樣會存在可怕的問題。
n+1問題的產生過程：為了從N個entity bean中獲取數據，首先必須調用finder方法（作為一次數據庫調用），在一個finder方法執行之後或者在一個商業方法調用之前，容器為每個entity bean執行ejbLoad()，這就是說，每個entity bean都要調用ejbLoad()方法（每個entity bean執行一次數據庫調用），這樣一個簡單的數據庫查詢操作就需要n+1次數據庫調用。每一次的數據庫調用都會在連接池中臨時鎖定數據庫連接。通常分布式系統的數據庫一般都單獨放在一台機器上，這樣每次的數據庫往返操作都會增加一次網絡調用。整個系統的速度就受到了影響。對我們這個例子來說，運行這個例子實際將需要2n＋1次數據庫調用(1個查找finder，n個employee ejbLoad(),n個department ejbLoad()).
2)遠程調用過多
如果要經過entity bean的遠程接口，對n個employee & department數據來說就需要3n次遠程調用
◆為每個employee的getvalueObject有n次調用
◆................getDepartment ........
◆......department的getvalueObject有n次調用
在獲取每個數值對象集後，session bean將把這些數值對象綁定到EmployeeProjectVIEwObject上。
3)簡單的聯結操作(join Operation)過於繁重。對這個例子來說，不管是BMP還是CMP，都要實例化許多的entity bean,和處理entity bean之間的交互。設想一個稍微復雜一點的情況，就是需要顯示employee及相關的department,project & company，這樣就不是僅僅增加幾十行代碼的問題，由於要增加數據庫調用和遠程調用，整個系統的速度將大大的降低。
4)需要創建一個數值對象層，使用entity bean層進行數據庫操作，需要實現value Objects,Subset value Objects & VIEw value Objects.這樣增加了代碼的復雜性降低了可維護性。在我們的這個例子中，我們創建了數值對象視圖，來封裝從deployee bean & department bean中獲得的數據，並且把他們匹配發送到客戶端。請閱讀"Generic Attribute Access"來進一步了解數值對象(value Object)的使用。
當客戶端只是浏覽數據時，使用entity bean層的優點就不是很明顯。使用本地接口和一個好的CMP實現將明顯得減少以上這些問題。但是BMP開發者就不會如此幸運。在BMP中，只能通過使用entity bean緩存來減少這樣的問題，而這只能用在單個EJB server部署上，並且要求數據庫的結構在ejb之外不能改變。否則的話，你只好忍受這些問題了。
還有既然客戶端需要列表顯示數據，這樣將數據庫中的數據轉換為對象的優點也就體現不出來了，因為還要將對象的數據在客戶端列表化。
鑒於以上問題：
在BMP中，使用JDBC從關系數據庫取出數據，使用RowSets將數據列表到客戶端，在使用Entity Bean來進行更新操作。
作為一個通常的笨拙的處理，你需要為客戶端列出數據，然後你在session facade模式下使用jdbc將比使用Entity Bean好的多。更重要的是，RowSets提供了一個清晰的和實際的方法從JDBC記錄集取出數據。然後直接列出到客戶端，而不需要先將數據轉化為數值對象再將數據列出到客戶端。
直接使用jdbc而不使用Entity Bean對許多開發者來說是不可思議的，自從Entity Bean出現以來，人們就一直在為此而爭論。畢竟，Entity Bean 很好的封裝了數據和數據邏輯，隱藏了持續管理的細節(比如：你不需要知道你所使用的數據庫是什麼)，使整個系統的商業概念模型化，使用了容器的許多特性，比如：連接池，並發性，事務等。如果使用一個非面向對象的方法，似乎是一種退步。但是同任何其他的設計模式一樣，有好處也有壞處，這些將在後面討論，不過我們先來看一下RowSets.
在ejb2.0中，RowSet 是一個接口，是Javax.sql.ResultSet的子類。RowSet的特殊實現允許你將ResultSet數據包裝並排列顯示到客戶端，客戶端可以直接操作RowSet記錄集合字段。jdbc2.0把這種實現稱作CachedRowSet.CachedRowSet並不連接數據庫，一旦它從ResultSet中把數據復制過來，就可以斷開與數據庫的連接，此時，CachedRowSet就存放了sql查詢的結果集。
對我們這個例子，使用RowSet，我們可以將一張表裡的所有數據一次性的存到一個對象中，並且發送到客戶端。下面的圖形顯示了RowSet方法與數值對象方法的區別
doc1.Html
在客戶端，從RowSet裡取出的數據可以直接對應到表格的行和列。
使用JDBC和RowSet的優點：
1)RowSet為所有的查詢操作提供通用的接口
2)簡單的查詢操作沒有事務過載
3)利用緩存中的數據庫
4)只返回你想要的數據
5)用戶所要的數據只通過一次大的調用
缺點：
1)用戶需要知道數據庫表的字段名
2)商業邏輯與持續邏輯之間的緊密耦合
3)不是面向對象的
4)在編譯期間不檢查查詢結果。
在數值對象中調用getXXX（）而用RowSet在客戶端需要調用getString("XXX")
5)有可能產生bug,可維護性差
最後，這個模式並不是說不要用Entity Bean，只說說當用戶只需要臨時列表顯示數據時，還有更高效的方法。在這個模式中，jdbc 和 RowSet用來進行列出數據操作而entity bean責負責更新操作。特別注意：盡管RowSets也可以進行更新操作並且可以保證與數據庫的同步，但是在應用程序中永遠都不要這麼用！
盡管在客戶端列表顯示數據時，商業/數據概念的完整性以及和其他商業概念的聯系顯得不是很重要，但是當進行更新操作時，這些概念就非常重要。Entity Bean封裝了數據以及對數據的"操作規則"。當更新Entity Bean的屬性時，Entity Bean有可能需要進行有效性驗證並更新同一個應用程序中其他的Entity Bean。
舉個例子：對一個應用程序中的Book和Chapter Entity Bean，當你修改Chapter Entity Bean章節標題時，Chapter將檢驗新的標題並且調用Book Bean讓它進行修改，然後Book Bean有可能在調用其他的Entity Bean進行相應的修改操作。
從Session Facade通過jdbc/RowSets進行更新操作迫使開發者書寫將商業邏輯和復雜的數據邏輯混在一起的代碼。所有的某個特殊的商業概念(business concepts)要求的規則(rules),關聯和驗證都必須以更新記錄和表的形式出現。
JDBC and RowSets for reading采用的是Session Facade模式，與value Object 和 Generic Attribute Access模式是不一致和不兼容的。value Object 和 Generic Attribute Access還可以進行更新操作
