好奇别人是否和我有同样的感觉。对我来说，datagrid/gridview/formview/等控件。非常适合演示或演示。要花时间调整这些控件，覆盖它们的默认行为（挂钩到它们的愚蠢事件等）是一件令人头疼的事情。我使用的唯一控件是中继器，因为它为我提供了比其他控件最大的灵活性。
简而言之，它们几乎是英国媒体报道的软件。
我宁愿编织我自己的 html/css，使用我自己的自定义分页查询。
同样，如果您需要快速打开页面，这些控件非常棒（尤其是当您试图吸引人们进入易于.NET开发的情况时）。
我一定是少数，否则 MS 不会在这些类型的控件上投入这么多的开发时间......
任何认为没有人使用 *Grid 控件的人显然从未在内部公司 web 应用程序上工作过。
我几乎在编写自己的 HTML - 我正在使用 ListView 和 Masterpages，但不再真正使用控件了。顺便说一句，我的 ListView 会嘲笑你那愚蠢的老中继器。
但是，英国媒体报道软件不一定是坏事。如果我需要构建一个低容量的 Intranet 应用程序，我宁愿付钱给经验不足的开发人员来拖放控件，而不是让 HTML twiddler（如你或我）来制作每个标签。绝对有一个快速，简单的方法的地方。只要基于控件的代码以可维护的方式编写，那么在这种情况下“膨胀软件”的成本是多少？通常将控件连接在一起需要较少的自定义代码，这意味着维护简单。
我必须不同意你的一个地方——几乎不管应用程序如何——是制作你自己的分页查询。你可能喜欢做那种事情，但它绝对没有商业价值。有几种专业级 DAL 工具通常会比大多数开发人员编写更易于维护、更快的查询。即使您精心设计了完美的分页查询，它也不会跟上模式的更改，除非您继续花费数小时。我认为更好地利用这些时间是构建一个轻量级系统并将这些时间用于监控和修复特定的瓶颈，而不是立即跳到“数据库汇编语言”层。
我一直在阅读您的帖子，这让我感到很愚蠢。
我的意思是，在我工作的每个应用程序中，至少有一个数据网格/网格视图。而且我没有感觉到我错过了什么。
当然，我发现 datagrid/gridview 有点臃肿，但它们使用起来有那么恶心吗？
我认为您需要在谴责它们之前学习使用 GridViews。我广泛使用它们。起初，弄清楚某些事情有点挑战性，但现在它们是不可或缺的。
UpdatePanel 中带有 AJAX CRUD 和分页的 GridView 速度非常快。以这种方式设置的较大系统之一（用于内部/外部应用程序）在后端有一个中等大小的数据库。有许多 nvarchar(2000) 字段，转换和更新都很棒。
无论如何，如果您已经编写了自己的显示数据版本，那么您可能希望继续使用它（如果它有效）。（对于编写自己的编译器、编写自己的 HTML 版本、编写自己的数据访问二进制文件版本都可以提出相同的论点……）使用 GridView 的优点是有很多人熟悉它，并且MSFT 已经对这个类进行了抽象/建模，以完成很多我们过去必须手动完成的事情。
我们在公司开发的每一个应用程序都有网格（这些应用程序都在防火墙后面）。这包括 Web 应用程序和 Winform 应用程序。对于 web 应用程序，它是很好的 ole gridview，为我们使用 Janus 网格的 winform 应用程序提供自定义排序。我试图让开发人员/用户考虑更好的用户界面，但很难改变。我必须承认它仍然比用户使用 Access 构建他们“自己的”应用程序的替代方案更好，然后我需要支持！
使用像 GridView 这样的控件非常适合简单的应用程序。即使你是一个服务器端的 HTML 括号忍者，他们也可以让开发简单的东西花费更少的时间。问题是他们通常最终会开始暴露他们的缺点，而你最终不得不花时间调整它们。但至少你可以起床并快速开始。
例如，GridView 中的默认分页不支持数据库本身的分页（您必须在分页之前加载所有行），因此一旦您开始感觉到性能受到限制，您可能需要考虑滚动你自己的，或者更好的是，找到一个更强大的网格控件。
无论如何，关键是预先构建的组件是好的。他们帮助。但像往常一样，这取决于你需要他们做什么。
实际上，我已经将 GridView 广泛用于管理控制台。我什至创建了一个自定义的DataFieldControl，它根据数据字段设置字段的标题文本和排序表达式，在底部创建一个插入行并自动收集行中的值并将它们转发到数据源的插入方法，并生成一个列表框如果指定了其他列表数据源。尽管需要花费大量时间来构建它，但它确实非常有用。
我还有另一个控件，当没有记录时（在 EmptyDataTemplate 中），它将根据字段的元数据生成一个新的数据表单。
<asp:GridView ...>
<Columns>
<my:AutoField HeaderText="Type"
DataField="TypeId"
ListDataSourceID="TypesDataSource"
ListDataTextField="TypeName" />
</Columns>
<EmptyDataTemplate>
<my:AutoEmptyData runat="server" />
</EmptyDataTemplate>
</asp:GridView>
我喜欢 GridView 控件，并在我公司网站的几个自定义 DotNetNuke 模块中使用了它。一方面，使用内置控件意味着更少的依赖关系需要担心。一旦我按照我想要的方式设置它，我基本上将代码复制到其他页面，只需要做一些小的调整。
我发现现代网格控件（Infragistics、Telerik 等）有很多选项，配置网格比其他任何东西都需要更长的时间。MS 控件非常简单，但它们几乎可以做任何事情。
它们是 asp.net 的好处之一。直到最近我还讨厌它们，但是你使用它们的次数越多，它们就会变得越容易，一旦你了解了必须为哪些实例更改哪些设置。主要是我喜欢表单视图和列表视图，gridview 仍然需要一些工作。
对于我的企业内网项目，网格是必不可少的。它们是在 ASP.NET 网络表单平台上轻松报告的基础。
易于设计 在页面上粘贴网格。插入 BoundField 对象以进行简单绑定。asp:HyperlinkField 便于链接。
捆绑
您可以通过多种方式绑定网格：
List、ArrayList、Hashtable或任何简单的集合）SqlDataReader在您的代码隐藏中（是的，这将需要您的表示层中的 SQL）SqlDataSource（指定一个存储过程。结果集上的所有列都直接映射到网格的列。如果报告不能很好地模仿您的域对象，那将是非常快速和肮脏的。即不同事物的总和。）对于那些可能会调用SqlDataSourceand的人ObjectDataSource，您不必总是在 .aspx.cs 或 .aspx.vb 中声明它们。我不是在这里提倡它们，只是指出可能性。
我认为您不能忽视内置 GridView 和其他第 3 方网格的 RAD 优势。管理类型喜欢并想要表格数据。
我真的很喜欢telerik radgrid。他们的产品并不便宜，但是您可以获得很多控件和功能。并且数据绑定支持非常好，无论是简单的 asp.net 数据源绑定方式还是更自定义的处理你自己的数据绑定事件的方式。
在我的公司，我们到处使用网格，主要是 ComponentArt Grid ( http://www.componentart.com/ )。是的，它是过时的软件，但你会得到很多重新发明不会很有趣的功能：排序、分页、分组、列重新排序、内联编辑、模板（服务器端和客户端）。客户端 API 也不错。
一旦我开始从用户故事而不是从数据库表需求开始设计，我就基本上放弃了网格。并且永远不可编辑的网格。旧的方式就是我们强迫用户为我们的系统进行数据输入/表格维护，它与他们的工作流程不匹配——任何真正的工作最终都会从一个主/子表单跳到另一个。
用户从来没有弄明白——但他们肯定知道我们的应用程序比他们应该的更难使用。
一个例外是分析应用程序。但是其中相对较少，而且它们在很大程度上是只读的。
I too would like to see an expanded answer on why GridView et al are considered "bloatware." I have extensively used GridView as well as 3rd party products (Telerik, etc) and find that for the majority of internal and some external projects, they work great. They are fast, easy to use, customizable - and BEST - I can hand them over to someone who knows GridViews who can then easily pick up where I left off. If I were to hand-code all of the numerous apps/controls, the overhead in the next person figuring out what is going on would be enormous even under the best of circumstances.
For me, I can see some of the 3rd party products being bloatware (but still sometimes useful), but the bare-bones GridView I've found to be quite fast with moderate queries.
我们在内网应用程序上使用 Infragistics UltraWebGrid + LinqDataSource。
它为我们提供了 ajax、排序、过滤、分页所有服务器端。
“导出到 excel”也是一个杀手级功能。
我们有 5000 多个用户，大量的数据，性能非常好。
GridView/FormView/DataGrid 等组件遵循 80/20 规则。
这意味着当您将它们用于简单目的时，80% 的时间它们都能完成工作并且非常容易实现。
但是有 20% 的时间你会尝试构建复杂（或奇怪）的东西，并且你将被迫跳过十几个圈并以多种方式弯曲代码以尝试实现解决方案。
诀窍是了解问题是 80 问题还是 20 问题，如果您能及早识别 20 问题，您最好自己从头开始编写代码并放弃“节省时间”的代码。
我在我工作的企业环境中广泛使用它们，我现在正在使用它们。不使用它们的人让我想起了过去几年所有“我用记事本构建”的开发人员。如果您不打算利用节省的时间，那么使用 asp.net 有什么意义呢？
我从来没有使用过它。我完全同意，这是英国媒体报道。我通常最终使用带有我制作的自定义控件的中继器。
对于任何长期的事情，我都会尽量避免使用 datagrid/gridview，它有时会变得太笨拙，让它完全按照你的意愿去做，经过一定数量的这些调整后，你开始意识到从长远来看它不会节省时间，你可能不会控制您需要的标记。
然而，内置的分页和排序功能运行良好，并且在 2008 年有一个新的 ListView 控件，旨在解决其中的一些问题，并让您更严格地控制输出的 html。
我以前从未真正使用过标准的 WinForms 网格，但在我上一份工作中，我们广泛使用了 ComponentOne FlexGrid，它运行良好。尝试获得我们想要的所有定制仍然有一些烦恼，但总的来说它为我们节省了大量时间并产生了漂亮的结果。
目前我正在使用 Silverlight 3 和 RIA 服务，我无法想象在没有 DataGrid 和 DataForm 控件的情况下尝试产生我们正在做的事情。节省的时间远远超过任何开销。
我想这个问题很久了。这里似乎有一个共识，即网格控件是过时的软件。但是，任何人都可以明确列举使用这些控件的成本吗？是否有过多的 HTML 发送到浏览器？服务器消耗了太多资源？生成 HTML 表格是否更快（假设它写得很好）？
除了 bloatware 问题之外，当 UI 要求被增强以包含超出标准控件范围的功能时，我经常搁浅。例如，在早期的 ASP.Net 版本中，我很难将图像放在列标题中。而且，我相信添加第二个跨越多列的顶级标题行仍然是一个挑战。在某些时候，很难与控件搏斗以达到预期的效果。如果您知道您想要的 HTML，但您无法让控件执行此操作，这会令人沮丧。
在一个项目中，我最终放弃了，自己写了一个 HTML 表格类来生成一个非常复杂的网格。花了几天时间才把它弄好。但是，现在我有了基本代码，为未来的网格调整它会更有效率。
不过，毫无疑问。如果您能在它们的限制范围内生活，那么很难击败花哨的网格控件以实现快速开发。
如果您经常在面向公众的网站上与设计师合作，那么您应该放弃 GridViews 并坚持使用中继器。无论如何，这就是我的意见——我不得不拆开数百个 GridView 并将它们变成简单的转发器，以满足设计要求。
如果您在面向公众的网站上靠近带有 10 英尺杆的 DataGrids 或 GridViews，那么您必须使用 CSS 友好的控制适配器。（此时您可能会发现在中继器中执行此操作更容易。）在控制适配器可用之前，我会考虑这些控件是开箱即用的。
我发现太多的 .NET 开发人员对设计、可访问性、CSS、javascript、标准等没有很好的理解，这就是他们屈服于 GridViews、ObjectDataSources 等的原因。
GridView 是精细且非常强大的控件，可以很好地与 css 或主题配合使用。唯一让我烦恼的是，当旧的 1.1 DataGrid 在 asp.net 2.0 中被 GridView 替换时，VirtualCount 属性被删除，它对于实现自定义分页很有用。然而，同样可以通过数据适配器完成。
尽管使用中继器可能更清晰，并且您可以完全控制呈现的 html，但我仍然不建议这样做，因为更难实现和维护。
我是一个中等水平的开发人员，我可以说没有这些控件我永远学不会开发。只是你必须承认自己一段时间，直到你找到自定义它的方法，最终结果会很棒
我试图在上下文中查看这一切。我的页面有一个不错的 gridview（一次显示 10 行、6 列、排序和分页），如果我只查看与视图状态一起创建的 html 表，我只会看到 29k 的代码.
使用中继器或列表视图的 29k 与 18k 真的值得在这些宽带时代付出所有努力吗？
我个人坚持使用gridviews，但是与我一起工作的设计人员有时会抱怨尝试通过css对其进行样式设置。
只是看你的帖子。我同意 PHP 比 asp 更容易。但我刚开始使用 Visual Studio 的 formviews 和 gridviews。对 vb 或 C# 程序员来说都不容易。ASP 在上传大文件时仍然存在问题。PHP 它是一个快照。我在 IIS 7.5 下运行 PHP