C#教程之列表视图如何提供数据访问的几种方式

 数据访问模式概述

 

 

在模型编辑器中，通过 视图-> <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模式并没有什么意义。