Asp.Net GridView：好或坏/用于绑定的数据类型是什么？

Question

所以，这个问题可能有点模糊，但我一直在讨论它：

在设计 Asp.Net 页面时，很多时候您可能只想在页面上放置一个快速而肮脏的 GridView。当你走这条路时，你有各种数据源选项（我通常使用绑定到业务对象的 ObjectDataSource），你也可以手动绑定。

我看到了很多关于哪些数据类型可以在网格中自动提供排序功能的变化。我见过人们将他们的自定义 POCO 集合直接翻译成业务对象中的 DataTable，以便 GridView 可以更轻松地支持这些类型的行为。

您真的可以通过自己处理所有可用事件（OnSorting、OnUpdating 等）从 GridView 中获得许多不同的行为，从长远来看，它最终可以高度定制。即使是这种情况，您也可能会遇到偷偷摸摸的其他小问题，例如无法使用“Enter”键自动执行给定行的更新操作。这是因为页面上的默认按钮可能在 GridView 之外，并且 ASP.Net 只允许您为给定面板指定默认按钮，并且不支持 GridView 模板内的按钮的这种行为。这只是一个例子，请注意。当然还有一个问题是页面是否应该在每次过滤操作时返回数据源，或者整个数据源是否应该缓存在页面上的 ViewState 中以允许过滤/排序而无需访问数据库...

所以这是最终的问题：在需要基本 CRUD 操作的页面上使用 GridView 是否合理，即使这可能意味着将自定义集合转换为某种 DataTable？是否应该完全放弃 GridView 以支持 DataList、ListView 或 Repeater 之类的其他东西？后面的选项当然可能更灵活，但这是否意味着应该为每个场景重新构建 GridView 的默认行选择、编辑、排序等功能？

对此主题的任何合理想法表示赞赏！

Answer 1

我刚刚意识到这个问题仍然存在，所以这是我对这个话题的结论：

我仍然认为在 ASP.Net 页面中嵌入标准 GridView 控件很有用。我仍然认为在页面的代码隐藏中处理每个排序事件是不合理的，因为它会导致真正的维护噩梦，并且猛烈抨击您的数据交互和业务逻辑代码过于接近 MVC 术语中的“视图”。. .

我不知道 GridView 可以与各种 DataSource 控件紧密集成。我知道，在适当的情况下，连接到 SqlDataSource 的 GridView 会在应用自己的排序和分页技术时直接对数据库执行各种 CRUD 操作，但这并不能很好地转化为将 ObjectDataSource 与业务对象一起使用 - 或者我想。

事实证明，ObjectDataSource 控件具有三个关键属性，这使得它可以动态地为业务对象提供具有排序和分页参数的方法。

这些属性是：SelectCountMethod、SortParameterName、StartRowIndexParameterName 和 MaximumRowsParameterName。这些属性与所需的 EnablePaging 标志一起更改“Select”方法的预期签名，并使用 SelectCount 方法自动启动以获取可能返回的记录总数，使用 GridView 的页面大小和当前状态来确定从哪里开始您的结果集以及在该起点之外选择多少项目，并开始提交 SQL 样式的排序表达式以及对您的 Select 方法的所有调用。

总而言之，这是向前迈出的一大步，但是如果您使用 POCO 类的自定义集合，或者针对 LinqToSql 或 EF 对象上下文执行查询，您仍然需要将 StartRowIndex 和 MaximumRow 参数转换为某种形式的Skip().Take() 组合（非常简单明了）并将 Sort 表达式转换为针对您的对象上下文或内存中集合的某种类型的查询。

我不会在这里详细介绍所有冗长的细节，但基本上解决方案是使用动态 Linq 功能和反射来定义针对您的内存中集合的查询表达式，仅使用排序字符串继续。

排序字符串将包含典型的“字段名称 DESC”格式的字段名称和排序方向（仅当降序时）。通过解析此字符串，您可以使用特定类型的反射来使用排序字符串中的匹配属性名称创建表达式。

这里的主要好处是，只需对 select 方法进行一些调整，并使用自定义 Linq 扩展来处理将排序字符串转换为 lambda 表达式，您就可以开始将 GridViews 连接到业务的常规业务具有内置排序和分页功能的逻辑。

因为在最初的问题中提到过，所以我会注意到，这种解决方案几乎会在每次页面加载时都对数据库造成冲击，但最终返回的数据量应该会小得多，而且更有针对性。

Answer 2

多年来第一次不得不再次使用gridviews，我想起了为什么我这么久没有使用它们。 Gridviews 非常适合它们在基本级别上的设计，但不幸的是，大多数时候最终用户会想要更多的功能，而这正是他们开始不足的地方。虽然您可以自定义和扩展网格视图，但正如您所指出的，这会打开一个完全不同的蠕虫罐。所以对我来说，我尝试坚持使用网格视图作为生成报告的工具。除此之外的任何事情，我似乎都花了很多时间来定制和调整它，以获得接近我需要的东西，但这不值得付出努力。