我已经看到了很多讨论，人们在问有关WPF的DataGrid的问题，并抱怨微软直到现在还没有使用WPF框架。我们知道WPF是一种很棒的UI技术，并且具有ItemsControl，DataTemplate等概念来制作出色的UX。甚至WPF都具有更紧密匹配的controlListView，可以轻松地对其进行模板化，以提供比传统的Datagrid显示器更好的UX。我想说一个现成的DataGrid控件将杀死或者隐藏很多创意，并且肯定会减少User Experience领域的创新。

那么，我们对WPF中作为框架组件的DataGrid的需求有何看法？如果我们觉得有必要，那仅仅是因为世界已经习惯了DatGrid多年的数据显示方式吗？

有关DatGrid的其他一些讨论在这里和这里

链接到WPF ToolKit最新的WPF DatGrid

解决方案

DataGrid非常适合显示绑定到后备存储的大量表格数据。

但是在WinForms世界中发生的事情是，人们经常将它们用于需要多元素滚动列表的所有内容。汇总的第三方DataGrid很快就可用，它允许列和字段包含按钮，组合框和图标等。

DataGrid成为主力军，因为需要将其哄骗为某种行为。在通用集合出现之前，DataTable发生了类似的情况-当我们使用大量DataTable时，在UI中使用DataGrid呈现它是阻力最小的途径。

我认为，当WPF出现时，像我这样的许多程序员仍在以这种方式思考，并寻求DataGrid概念的WPF端口。

无法想到更好的控件来显示表格数据，尤其是在我们不想通过模板化/开发(Headered)ItemsControl使其表现得像旧的DGV来重新发明轮子的商务应用程序中。我确定你看到了。

是的！
ms无法提供的许多其他控件。 (Datepicker，NumericControl)

MS首先应该给我们提供完成工作的工具，这是我对wpf炒作的编程环境的最低期望。

与WPF合作大约2年之后。我要说的是，DataGrid实际上只是一个荣耀的ListBox(因为[几乎] WPF中的所有内容都是无样式的)。

可以设置一个ListBox样式以采用某种Entity，并为每个条目显示一个"记录"控件。根据它们制作的灵活性，它们可以根据传递的实体自动进行调整。

这是必不可少的，但是使用GridView的ListView可以达到几乎相同的效果，不是吗？

是的，DataGrids将永远不会作为必不可少的业务UI组件而消失。人们喜欢他们的电子表格，我们希望分享这种爱！

请注意，MS交付了这些额外的控件，它们已经在CodePlex上创建了WPF工具包，以提供快速周转的开源样式的部署。

它已经包括一个DataGrid和Calendar。

没有人反对我们可以在WPF中创建DataGrid控件。关于WinForms，也许会说同样的话，尽管会更加困难。我已经实现了ListView的一些功能，呈现表格数据非常容易，甚至可以说它得到了很好的支持。但是，编辑ListView所需的代码量(手动编写的代码)非常庞大。

业务应用程序通常需要编辑许多表，并且我们不想变得有创意，而是想快速。我认为这就是为什么需要DataGrid的原因。