DevExpress aspxgridview 与 LinqServerModeDataSource 或用于快速过滤和排序的替代方案
DevExpress aspxgridview 与 LinqServerModeDataSource 或用于快速过滤和排序的替代方案
我们正在尝试生成一个只读的结果网格，其中速度是优先考虑的。当前使用 gridview 控件，对单击时选择行和固定页眉/页脚进行一些自定义。数据访问来自对象数据源或来自我们业务层的代码绑定，数据库是 SQL Server 2008。
计划是为 gridview 购买第 3 方控件，并且一直在关注 DevExpress aspxgridview。我们希望能够向 gridview 数据添加属性、过滤并非常快速地绑定网格，并查看了 LinqServerModeDataSource，这可能意味着解决方案中需要另一种数据访问技术，但对于任何阅读都会对此感到满意仅查询我们可以轻松地在数据库中快速进行连接和排序的查询，但使用 n 层 BLL / DAL / DTO 进行任何插入 / 更新 / 删除。
大家对这个计划有什么想法吗？ LinqServerModeDataSource 和 aspxgridview 是否可以快速显示数据并提供将过滤器（联接/存在查询）堆积到我们绑定到的表上的选项，或者是否有更好的方法来执行此操作。 （我假设我们需要在 LinqServerModeDataSource OnSelecting 中编辑 linq 查询）不想编写任何自定义 ajax 或 html 并让自定义控件执行此操作。
DevExpress aspxgridview with LinqServerModeDataSource or alternative for fast filtering and sorting
We are trying to produce a read-only grid of results where speed is the prioirity. Currently using a gridview control with some customization for select row on click and fixed header / footers. Data access is from either objectdatasource or code binding from our business layer, database is SQL Server 2008.
The plan is to buy 3rd party controls for the gridview and have been looking at DevExpress aspxgridview. We would like to be able to add attributes to the gridview data, filter and very quickly bind the grid and have looked at the LinqServerModeDataSource, This would probably mean having another data access technology in the solution but would be happy with this for any read-only queries where we can easily do joins and sorts quickly at the database but use the n-tier BLL / DAL / DTOs for any insert / update / deletes.
Does anyone have any thoughts on this plan. Would the LinqServerModeDataSource and the aspxgridview be quick to display data and give the options to pile on filters (joins / exists queries) to the table we are binding to or is there a better way of doing this.
(I assume we would need to edit the linq query in LinqServerModeDataSource OnSelecting) Would prefer not to write any custom ajax or html and let a custom control do this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当 ASPxGridView 绑定到 LinqServerModeDataSource 时，所有与数据相关的操作都在数据库服务器上执行。在这种情况下，数据源向数据库服务器发送许多请求，但所有这些请求都很轻，即它们应该快速执行并且不会导致传递到Web服务器的大量数据。另外，我想警告您，在服务器模式下工作的网格有一些限制，我们的帮助中对此进行了描述：
服务器端数据管理
最后，我认为ASPxGridView在服务器模式下工作非常快，你最终应该尝试一下。但是，仅当底层 DataSource 返回大量数据时才应使用服务器模式。否则，当所有内容都在 Web 服务器上管理时，最好使用“经典”绑定模式。
更新
我将尝试解释什么时候需要服务器模式。默认情况下，所有网格控件（标准的，我们的……）都会从数据库服务器获取所有数据到 Web 服务器并对其进行管理。例如排序。如果数据量较小并且数据库和Web服务器之间的连接很快，则此操作完成得相当快并且不需要服务器模式。从我的角度来看，5k 条记录并不是大数据，因此 ASPxGridView 的代码应该能够有效且快速地处理它。但是，如果Web服务器上需要处理的记录很多，例如100k，那么图片就不一样了。显然，将 100k 数据获取到 Web 服务器并通过网络传输可能会很慢。此外，数据库服务器经过优化，可以更好地处理此类数据，并且应该管理这些数据，例如，更快地对它们进行排序。在这种情况下，将这项工作传播到数据库服务器并获得性能会更有利可图。
因此，决定是否使用服务器模式必须使用的主要标准如下：
从数据库服务器传递到 Web 服务器的记录数量以及管理它所需的时间。
希望这有帮助。
When ASPxGridView is bound to a LinqServerModeDataSource all data related operations are performed on the DB server. In this situation, the dataSource sends many requests to the DB server but all these requests are light, i.e. they should be executed fast and do not result in large data passed to the web server. Also, I would like to warn you that the grid working in server mode has some limitations and they are described in our help:
Server-side Data Management
Finally, I think that ASPxGridView working in server mode is very fast and you eventually should give it a try. However, a server mode should be used only when an underlying DataSource returns a lot of data. Otherwise, it is better to use the "classic" binding mode when all is managed on the web server.
Update
I will try to explain at which point a server mode is needed. By default, all grid controls (standard, our ...) fetch all data to the web server from the DB server and than manage it. For example, sort. If a data size is small and a connection between DB and web servers is fast, this operation is done fairly fast and a server mode is not needed. From my point of view, 5k records is not large data and thus the ASPxGridView's code should work with it effectively and fast. However, if there are a lot of records which should be processed on the web server, for example, 100k the picture is different. Obviously, fetching 100k to the web server and transferring them via net can be slow. Also, the DB server is optimized to work with such data much more better and it should manage this data, for example, sort them faster. In this case, it is more profitable to propagate this work to the DB server and gain the performance.
So, the main criteria which must be used to decide whether or not to use a server mode is the following:
the number of records passed from the DB server to the web server and the time needed to manage it.
Hope, this helps.