好奇别人是否和我一样。对我来说，诸如datagrid / gridview / formview / etc之类的控件。仅适用于演示或者演示。要花时间调整这些控件，覆盖它们的默认行为(钩住其愚蠢的事件等)是一件令人头疼的事情。我使用的唯一控件是转发器，因为它为我提供了比其他转发器更大的灵活性。

简而言之，它们几乎是膨胀软件。

我宁愿编织自己的html / css，使用自己的自定义分页查询。

同样，如果我们需要快速浏览这些页面，则这些控件非常有用(尤其是当我们试图吸引人们参加.NET开发的便捷性时)。

我必须是少数派，否则MS不会在这些类型的控件上投入那么多的开发时间...

解决方案

回答

我真的很喜欢Telerik Radgrid。他们的产品并不便宜，但是我们可以获得许多控件和功能。而且，数据绑定支持非常好，既有简单的asp.net数据源绑定方式，也有更自定义的处理我们自己的数据绑定事件的方式。

回答

我几乎是在使用ListView和Masterpages编写自己的HTML，但实际上不再使用控件了。顺便说一句，我的ListView嘲笑老傻瓜中继器。

但是，bloatware不一定是一件坏事。如果我需要构建一个低容量的Intranet应用程序，那么我宁愿花钱少一些经验丰富的开发人员拖放控件，而不是用HTML旋转器(如我们或者我)来制作每个标签。绝对有一种快速简单的方法。只要以可维护的方式编写基于控件的代码，在那种情况下"膨胀软件"的成本是多少？通常，将控件连接在一起需要较少的自定义代码，这意味着易于维护。

无论应用程序是什么，我都不得不同意意见，这是在编写自己的分页查询时。我们可能喜欢做这种事情，但是其中绝对没有任何商业价值。有几种专业级DAL工具通常会比大多数开发人员编写更可维护，更快速的查询。即使我们精心制作了完美的分页查询，它也不会跟上对模式的更改的最新更新，除非我们继续在此之后花费数小时。我认为更好地利用这些时间是建立一个轻量级的系统，并将这些时间用于监视和解决特定的瓶颈，而不是立即跳到"数据库汇编语言"层。

回答

实际上，我已经将GridView广泛用于管理控制台。我什至创建了一个自定义DataFieldControl，该控件设置字段的标题文本和基于数据字段的排序表达式，在底部创建一个Insert行，并自动收集该行中的值，并将它们转发到数据源的insert方法，并生成一个列表框如果指定了其他列表数据源。尽管花费了大量时间进行构建，但它确实非常有用。

我还具有另一个控件，当没有记录时(在EmptyDataTemplate中)，该控件将基于字段的元数据生成新的数据表单。

<asp:GridView ...>
 <Columns>
       <my:AutoField HeaderText="Type" 
                      DataField="TypeId"
                      ListDataSourceID="TypesDataSource"
                      ListDataTextField="TypeName" />          
  </Columns>

    <EmptyDataTemplate>
        <my:AutoEmptyData runat="server" />
    </EmptyDataTemplate>

</asp:GridView>

回答

在我公司，我们到处都使用网格，主要是ComponentArt网格(http://www.componentart.com/)。是的，它是过时的软件，但是我们会获得很多重新发明的功能，这些功能并不是那么有趣：排序，分页，分组，列重新排序，内联编辑，模板化(服务器端和客户端)。客户端API也很不错。

回答

我一直在看你们的帖子，这让我感到愚蠢。

我的意思是，在我工作的每个应用程序中，至少都有一个datagrid / gridview。而且我没有感觉到我缺少什么。

当然可以，我发现datagrid / gridview有点肿，但使用起来有那么多恶心吗？

回答

任何认为没有人使用* Grid控件的人显然从未在内部公司Web应用程序上工作过。

回答

我喜欢GridView控件，并在我公司的网站的几个自定义DotNetNuke模块中使用了它。一方面，使用内置控件意味着更少的依赖关系。设置好所需的功能后，我基本上将代码复制到了其他页面，并且进行了一些细微的调整。

我发现现代网格控件(Infragistics，T​​elerik等)有太多选择，因此配置网格所需的时间比其他任何方法都要长。 MS控件非常简单，但几乎可以做任何事情。

回答

它们是asp.net的优点之一。直到最近，我还是讨厌它们，但是一旦学会了必须为哪些实例更改设置，就越会使用它们，它们就变得越容易使用。主要是我喜欢窗体视图和列表视图，而网格视图仍需要一些工作。

回答

我们公司开发的每个应用程序都有网格(这些应用程序都位于防火墙后面)。这包括Web应用程序和Winform应用程序。对于Web应用程序，这是一个很好的ole gridview，它具有针对我们使用Janus网格的winform应用程序的自定义排序功能。我正在尝试让开发人员/用户想到更好的用户界面，但是要进行更改很难。我必须承认，它仍然比使用Access构建自己的"自己的"应用程序的用户更好，那我需要它来支持！

回答

使用GridView之类的控件非常适合简单的应用程序。即使我们是服务器端HTML括号缠结的忍者，他们也可以使开发简单的东西所花的时间大大减少。问题在于，他们通常最终会开始暴露自己的缺点，而我们最终不得不花时间来调整它们。但是至少我们可以起床并快速开始。

例如，GridView中的默认分页不支持数据库本身的分页(我们必须先加载所有行，然后才能对它们进行分页)，因此一旦开始感到性能受到限制，我们可能需要考虑滚动我们自己的，或者可能更好的是，找到功能更强大的网格控件。

无论如何，关键是预构建的组件是好的。他们帮助。但是像往常一样，这取决于我们需要他们做什么。

回答

我没用过我完全同意，它是过时的软件。我通常最终将中继器与我制作的自定义控件一起使用。

回答

从长远来看，我会尽量避免使用datagrid / gridview，它有时变得太笨拙，无法完全按照要求进行操作，经过一定数量的调整后，我们开始意识到它并不能节省时间，从长期来看，获得所需标记的控制权。

但是，内置的分页和排序功能效果很好，并且在2008年提供了一个新的ListView控件，该控件旨在解决其中的一些问题，并为我们提供对输出html的更严格的控制。

回答

我很想知道这个很长时间了。这里似乎已经达成共识，即网格控件是过时的软件。但是，任何人都可以明确引用使用这些控件的成本吗？是否有过多的HTML发送到浏览器？服务器上消耗了太多资源？是否正在更快地生成HTML表(假设其编写正确)？

除了过时的软件问题之外，当UI要求得到增强以包含超出标准控件范围的功能时，我经常会搁浅。例如，在早期的ASP.Net版本中，我努力将图像放在列标题中。而且，我认为添加第二个跨多个列的顶级标题行仍然是一个挑战。在某个时候，要与控件进行搏斗以达到所需的效果真的很困难。如果我们知道所需的HTML，这将令人感到沮丧，但我们无法使控件做到这一点。

在一个项目中，我最终放弃并为自己编写了一个HTML表类，以生成一个非常复杂的网格。花了几天的时间才把它弄对。但是，现在我有了基本的代码，对将来的网格进行调整将更加有效。

毫无疑问，但是。如果我们只能忍受它们的局限性，那么很难击败花哨的网格控件来进行快速开发。

回答

对于我的公司Intranet项目，网格是必不可少的。它们是在ASP.NET Webforms平台上轻松报告的基础。

易于设计
将网格粘贴到页面上。插入BoundField对象以进行简单绑定。 asp：HyperlinkField便于链接。

捆绑

我们可以通过以下几种方式绑定网格：

• 对象的集合("列表"，" ArrayList"，"哈希表"或者任何简单的集合)
• 后台代码中的" SqlDataReader"(可能，这需要在表示层中使用SQL)
• SqlDataSource(指定存储的proc。结果集上的所有列都直接映射到网格的列。如果报表不能很好地模仿域对象，即不同事物的总和，这将是非常快速和肮脏的。)
• objectDataSource(绑定到BL上的方法)

对于那些可能会调用SqlDataSource和ObjectDataSource的用户，我们不必总是在.aspx.cs或者.aspx.vb中声明它们。我不是在这里提倡他们，只是指出了可能性。

我认为我们不能轻视内置GridView和其他第三方网格的RAD好处。管理类型喜欢并想要表格数据。

回答

如果我们在面向公众的网站上与设计师进行大量合作，则应放弃GridViews并坚持使用中继器。无论如何，这就是我的观点，为了满足设计要求，我不得不拆开数百个GridView，并将它们变成简单的中继器。

如果我们在面向公众的网站上以10英尺高的杆子靠近DataGrids或者GridViews，则必须使用CSS友好的控件适配器。 (这时，我们可能会发现在中继器中执行此操作会更容易。)在使用控件适配器之前，我会认为这些控件是开箱即用的。

我发现太多.NET开发人员对设计，可访问性，CSS，JavaScript，标准等没有很好的了解，这就是为什么他们屈从于GridViews，ObjectDataSources等。

回答

我认为在谴责它们之前，我们需要学习使用GridView。我广泛使用它们。起初，要弄清楚某些事情有些挑战，但是现在它们是必不可少的。

使用AJAX CRUD和分页的UpdatePanel中的GridView快如闪电。通过这种方式(内部/外部应用程序)设置的较大系统之一在后端具有中等大小的数据库。 nvarchar(2000)字段很多，并且过渡和更新很棒。

无论如何，如果我们编写了自己的显示数据版本，则可能希望继续使用它。 (可以为编写自己的编译器，编写自己的HTML版本，编写自己的数据访问二进制版本提供相同的参数。)使用GridView的优点是很多人都熟悉它并且MSFT已经对类进行了抽象/建模，以完成许多以前必须手动完成的工作。

回答

GridView是很好的控件，功能非常强大，并且可以与CSS或者主题完美配合。唯一让我感到烦恼的是，当在ASP.NET 2.0中将旧的1.1 DataGrid替换为GridView时，VirtualCount属性被删除了，这对于实现自定义分页很有用。但是，可以通过数据适配器完成相同的操作。
尽管与中继器的工作可能更清晰，并且我们可以完全控制呈现的html，但我不建议我们采用这种方式，因为难以实现和维护。

回答

我们在Intranet应用程序上使用Infragistics UltraWebGrid + LinqDataSource。

它为我们在所有服务器端提供ajax，排序，过滤和分页。

"出口到Excel"也是一个杀手feature。

我们有5000多个用户，大量数据，性能卓越。

回答

我是一个中等水平的开发人员，我可以说没有这些控件，我永远都不会学习development.just我们必须花一段时间来承认自己，直到我们找到自定义它的方法，最终结果会很棒

回答

一旦开始根据用户故事而不是根据数据库表要求进行设计，我就很大程度上放弃了网格。永远不要编辑网格。旧的方式就是我们强迫用户对系统进行数据输入/表维护，而它从未与他们的工作流程匹配，因此任何实际工作最终都从一种主/子形式跳到另一种形式。

用户从来没有想过，但他们确定知道我们的应用程序比应使用的更难使用。

分析应用程序是一个例外。但是其中的相对较少，而且大部分都是只读的。

回答

我也希望看到关于为什么GridView等人被视为"过时软件"的扩展答案。我广泛使用了GridView以及第三方产品(Telerik等)，发现对于大多数内部项目和一些外部项目来说，它们都很好用。它们是快速，易于使用，可自定义的，并且最好的是，我可以将它们交给认识GridViews的人，然后可以轻松地从我离开的地方取回它们。如果我要手工编写所有众多应用程序/控件的代码，那么即使在最好的情况下，下一个人弄清楚正在发生什么的开销也将是巨大的。

对我来说，我可以看到一些第三方产品是过时的软件(但有时还是有用的)，但是我发现使用中度查询时，基本的GridView很快。

回答

我正在尝试在上下文中查看所有内容。我的页面具有良好的gridview(一次显示10行，6列，排序和分页)，如果仅查看与viewstate一起创建的html表，那么我只会看到29k的代码。

在这些宽带时代，使用中继器或者列表视图的29k与18k真的值得吗？

我个人坚持使用gridviews，但是与我一起工作的设计人员有时会尝试通过css对其进行样式设置。

回答

我以前从未真正使用过标准的WinForms网格，但是在我的上一份工作中，我们广泛使用了ComponentOne FlexGrid，并且效果很好。尝试获得我们想要的所有定制仍然有一些烦恼，但总的来说，它节省了我们很多时间，并产生了漂亮的结果。

目前，我正在使用Silverlight 3和RIA Services，无法想象如果没有DataGrid和DataForm控件，就会产生我们正在做的事情。节省的时间远远超过任何开销。

回答

诸如GridView / FormView / DataGrid之类的组件遵循80/20规则。

这意味着80％的时间将它们用于简单目的时，它们就可以完成工作并且非常容易实现。

但是20％的时间，我们将尝试构建复杂(或者怪异)的东西，并且我们将被迫跳过十几个箍，并以多种方式弯曲代码以尝试实现解决方案。

诀窍是了解问题是80问题还是20问题，如果我们能及早发现20问题，那么从头开始编写代码并放弃"省时"的问题要好得多。

回答

我在工作的公司环境中广泛使用了它们，并且现在正在与他们一起工作。那些不使用它们的人使我想起了过去几年中所有的"我用记事本构建的"开发人员。如果我们不打算利用节省时间的优势，那么使用asp.net有什么意义呢？