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模式，有可能他们并没有什么差别。