XAF-列表視圖數據訪問模式，xaf-列表視圖模式

本主題介紹有關列表視圖如何提供數據訪問的幾種方式。請注意，選擇正確的方式對於實現XAF應用程序的最佳性能至關重要。

 

 數據訪問模式概述

 

 

在模型編輯器中，通過 視圖-> <ListView>節點找到IModelListView.DataAccessMode屬性，指定顯示的對象集合是如何被訪問。可用值- Client，Server，InstantFeedback和DataView。

提示

當通過使用IModelListView.EditorType屬性設置了不同的編輯器時，DataAccessMode中的值並不會隱藏掉不支持的模式。

如果您使用自定義列表編輯器，您可以通過靜態方法DataAccessModeHelper.RegisterEditorSupportedModes指定支持的模式。

您可以在加載模型編輯器之前（例如，從模塊的構造函數）在設計時執行的任何代碼調用此方法。將列表編輯器類型及其支持的模式列表傳遞到此方法。默認情況下，所有模式都可用於自定義列表編輯器。

默認模式是Client，這在大多數情況下，適當的使用Server，InstantFeedback和DataView模式是提升性能問題的好方法，但它們使用不同的優化方法。下表提供了每種模式的詳細說明。

Client:

在顯示列表時，一次性的將數據庫中的所有記錄都讀到客戶端（win是客戶端,web是讀取web服務器內存中），不管界面上顯示了多少數據，都先放到內存中去。執行排序、分組、分頁、過濾，時，都是去操作內存數據。

這看起來不錯吧，然後，在數據很多，關聯很復雜時，一次性加載這麼多會讓我們感覺很慢（比如幾萬條），也很占內存。

Server:

假設我們使用的是sql數據庫（oracle,mysql,mssql都算上），這種模式是使用sql語句進行分組、分頁、排序、過濾的，這樣會讓數據不需要全部返回，數據多時，壓力轉移到sql服務器。只加載顯示出來的部分，或一小部分數據，每次需要時，再去讀取。數據量大時，比起client快很多。

• 如果使用其表具有復合主鍵的舊數據庫，則無法使用此類表在服務器模式下提供數據。
• 如果你有一個自定義的控制器訪問的列表視圖列表編輯器的控件執行自定義排序或分組，控制器可能不再有效，因為分組和排序是由數據庫服務器執行的。自定義摘要也在服務器端計算。有關服務器模式的限制的其他信息，請參閱XtraGrid中服務器模式局限性的話題。
• 支持服務器模式的控件不能完全訪問底層數據，並且無法在客戶端啟動過濾，排序和分組操作。這些操作委托給底層的ORM（Entity Framework或XPO），它構造一個合適的SQL語句，並對SQL服務器執行查詢，以檢索應立即顯示給用戶的一小部分數據。您不能根據非持久化屬性過濾，排序和分組數據 - 不能針對客戶端上存在的運行時值構建SQL查詢，並在數據庫服務器上執行它。因此，如果屬性不是持久化的，則在服務器模式中禁用過濾，分組和排序操作。
• 目前，該服務器模式由兩個內置列表編輯器的支持下- GridListEditor，在Windows中默認使用窗體應用程序，以及ASPxGridListEditor，默認使用在ASP.NET Web應用程序。

　　實際使用中，遇到的較多的問題是：屬性不是持久化的，不支持過濾、排序功能。可以考慮用PersistentAlias來做服務端計算表達式，用了這個之後，我們基本可以放棄要使用sql語句的功能了。

InstantFeedback:

此模式與服務器模式非常相似。所不同的是，

該數據感知操作在後台線程異步執行(16.X中的新功能）

，並且控制繼續響應於用戶的操作，而被檢索到的數據（見即時反饋模式）。這就是為什麼上述常規（同步）服務器模式的限制也適用於即時反饋的原因。附加限制：

• 此模式是只能用於WinForms form中的GridListEditor。
• 不支持InLine編輯。
• 引用屬性排序時，分組和過濾被自動由相應的引用對象的默認屬性所取代。例如，在聯系人列表視圖中，Contact.Department.Title屬性是用來代替Contact.Department。

DataView:

一次性加載所有的數據，但不是轉換為ORM對象，返回的是數組。

• 不支持非持久化屬性，但可以使用計算字段。
•   引用型屬性不會直接顯示，但會用引用屬性中的DefaultProperty(通過XafDefaultProperty指定的)。
•   支持的控件-win：GridListEditor、 SchedulerListEditor、 PivotGridListEditor
• Web : ASPxGridListEditor、 ASPxSchedulerListEditor、 ASPxPivotGridListEditor 在 ASP.NET Web 。
• SchedulerListEditor 和 ASPxSchedulerListEditor 的編輯在此模式下不支持“資源”。
•   在嵌套的列表視圖中的鏈接、 取消、 新建、 刪除和編輯操作 都是被設計為禁用的。 ListView.CurrentObject、 ListView.SelectedObjects 和 SimpleActionExecuteEventArgs.SelectedObjects 的屬性返回視圖記錄的對象，而不是原始的業務對象。要獲得真正的對象，請使用 ListView.GetObject 方法。 如果你在viewcontroller中等代碼中使用了遞歸的取數據時，可以考慮使用Client模式，有可能他們並沒有什麼差別。

提示

 

• 您可以全局的修改所有列表視圖（除了自動生成的嵌套列表視圖）的數據訪問方式，設置IModelOptions.DataAccessMode的屬性選項節點即可。
• 所有手動創建的列表視圖，包括嵌套的列表視圖，默認使用IModelListView.DataAccessMode屬性值。
• 在代碼中創建CollectionSource並應用於ListView時，您可以使用CollectionSource.CollectionSource的構造函數中的dataAccessMode參數來指定模式。

注意

 

當你定義了一個集合屬性，但並沒有使用Association建立關系時，你應該使用Client模式，因為，沒辦法推導出如何過濾這個集合。

啥意思呢，你直接在代碼寫了個集合屬性：return new XPCollection<T>("條件");

XAF不可能使用服務端模式，因為“條件”是怎麼來的，是不可以確定的，不可以自動推算出來的，比如你是動態變化的，XAF也不知是啥規則。

重要

使用Server、InstantFeedback或DataView模式時，想顯示非持久化屬性時，應該用PersistentAliasAttribute或CalculatedAttribute屬性。

 

 

 如何選擇合適的數據訪問模式

 

 

服務器，InstantFeedback和數據視圖模式旨在改善列表視圖的性能，但應根據不同的場景。

• 如果數據庫請求數量是關鍵問題時，那麼就應該選擇DataView模式。在此模式下，所有數據記錄只請求一次，然後在客戶端執行分組，排序和過濾，無需額外請求。引用類型的屬性也會一次加載過來，產生的SQL就是left join。在DataView模式，只加載界面可見的列，如果理解成sql語句，則是 select a,b,c from xx ，而其他模式（Client和Server）則是加載所有的列,則是select * from xx *還有可能是更多，也會產生更多次請求，比如沒有設置顯示的加載引用型屬性，就會再生成幾次引用屬性的加載。

• 如果列表視圖啟動時間非常重要，那麼你應該選擇Server或InstantFeedback模式。在這些模式下，只有可見的對象都被第一次請求時加載。然而，滾動、 分組、 排序和篩選導致附加的數據庫請求-則是按需加載數據。

• 如果性能還不錯，只需使用Client模式。不要啟用Server，InstantFeedback或DataView，除非你發性能不能接受，或是找到了合適的模式時。務必記住本主題前面列出的限制。需要注意的是如果數據很少，Server和InstantFeedback模式並沒有什麼意義。