是时候为我的项目编写 GUI，我想知道使用什么技术。我的大部分 .NET GUI 开发都是在 .NET 1 和 2 中完成的，所以我对 Windows Forms 非常了解。我隐约知道WPF，但还没有尝试“进入它”。
Windows 窗体是死了还是死了？ WPF 是一项值得学习的好技术吗？它是未来，只是一个阶段，还是可以与 Windows 窗体并驾齐驱的技术？
此外，任何经验都会很高兴听到，尤其是来自广泛使用这两种经验的人。您如何发现在这两个框架中实现了类似的功能？
【问题讨论】：
WinForms 是死了还是死了？
没有。它没有进一步显着开发（即没有新的主要添加），但它在 .NET 4 中得到完全支持。
WPF 是一项值得学习的好技术吗？
是的。
是未来，只是一个阶段，还是可以与 WinForms 携手并进的技术？
您最终会转向 WPF，但也可以理解，现有的大量代码库是用 WinForms 编写的，并且没有在 WPF 中重写它们的商业案例。因此仍然支持 WinForms。
此外，任何体验都会很高兴听到，尤其是来自广泛使用这两种体验的人。您如何发现在这两个框架中实现了类似的功能？
从广义上讲，WPF 更具表现力。如果您将框架视为可以以各种方式组合在一起的一组乐高积木，那么 WinForms 积木要大得多 - 每个积木都可以做很多事情 - 因此将它们组合在一起的方法更少。很多时候，当你需要一些东西——但又不像现有的砖块那样，你必须从头开始编写自己的东西。在 WPF 中，砖块要小得多，并且可以以许多有趣甚至令人惊讶的方式组合。
举个具体的例子，考虑一下 WPF Button 如何成为一个可以承载任意内容的容器 - 不仅仅是 WinForms 中的图像+文本，还包括任何其他 WPF 控件或控件集。
与 WinForms 相比，WPF 也更容易编写动态布局。后者也有布局，但问题是它们是在视觉设计器中使用的皇家 PITA，并且通过代码编写 WinForms 组件初始化非常乏味。使用 WPF，您只需手动编写 XAML 标记，布局（和一般的控制树）非常自然地用 XML 表示。
部分源于上述，我发现 WPF 更容易本地化。一方面，这是因为您确实需要动态布局以实现可本地化（因为您事先不知道所有语言环境中字符串的长度）。 WinForms 对此的解决方案是不仅要考虑文本标签，还要考虑控件的位置和大小，作为“可本地化的属性”——因此如果翻译者发现字符串不合适，他应该自己重新排列表单上的控件。在 WPF 中，动态布局是默认方法，因此本地化程序只处理字符串。
WPF 绑定框架相当强大（即使很冗长，这要归功于缺少内联转换器），并且大力促进了 MVP，并且总的来说，模型/视图分离。这可以通过 2.0+ 中的 WinForms 来实现，我也尝试在那里实现，但它更乏味，尤其是在 null 处理方面，有时可能是rather buggy。
一个特殊的痛点是 WinForms 设计器与源代码控制交互的方式。这里有两个类似的问题。首先，设计器将编辑后的表单序列化为代码，有时布局中的微小变化会使设计器生成完全不同的代码（如果您编辑工具栏，这一点尤其明显），因为它会打乱代码行 - 即实际上它改变了一行中的单个属性值，但它也重新排序了所有内容。这导致了历史上的大量噪音（在查看差异时几乎不可能说出究竟发生了什么变化），但更重要的是，这意味着合并这些文件是一个令人头疼的问题。这通常发生在两个人同时使用同一个表单，然后一个人提交他的更改，另一个人尝试提交，发现文件同时被更改，尝试合并，查看差异，并跳出最近的窗口。
当您使用 WinForms 可本地化的表单时会发生一个非常相似的问题，它将一些属性推送到资源文件。同样，设计者非常喜欢对资源文件中的属性值进行重新排序，以应对任何微不足道的变化，所有这些问题都与前面描述的相同。
现在关于 WPF 的不足之处。一个主要问题是它相当复杂，并且对于仅具有 WinForms、VCL、VB 或其他类似“传统”框架经验的人来说可能会感到陌生。另一个问题是，在我看来，文档并不完美——它通常提供一个不错的概述，但很少涵盖极端情况，其中一些可能非常重要。 WinForms 也是如此，但那里可能的组合更少，因此也更少极端情况。
还有第三方组件的问题。 WinForms 已经存在很长时间了，有很多可用的，其中很多非常成熟。 WPF 相对年轻，仍在经历成长的阵痛，大多数第三方解决方案也是如此。
我在 WPF 中的一个特别讨厌的地方是它对文本进行抗锯齿的方式 - 大多数人认为与普通 Windows ClearType 相比，它的质量要差得多，尤其是在小字体上；请参阅this bug report 了解更多信息。这在 WPF 4 中已修复，但尚未发布，即使发布，您也可能希望在一段时间内坚持使用久经考验的真正 3.5 SP1；并且该修复不会被反向移植。
【讨论】：
WinForms 并没有消亡或消亡……它们只是无法提供 WPF 所能提供的相同用户体验（无需大量工作）。它们只是较旧的技术。
WPF 是一种很好的学习技术。它能够以更少的工作提供更丰富的用户体验。
使用 WPF 的模型肯定不同于 WinForms。我都使用过（WinForms 比 WPF/Silverlight 更多），对我来说最困难的转换是：
XAML，如果您有其他标记语言（如 MXML）的经验，这还不错。
数据绑定
界面事件处理（鼠标悬停效果、时间线等）
【讨论】：
WinForms 远未消亡。 WPF 只是一种处理 UI 的新方法，因为它促进了 WinForms 中更困难的事情。诸如将 UI 背后的模型与实际 UI 分离以便可以轻松测试之类的事情是一个重要因素。
这绝对值得学习，但请务必学习创建屏幕的“WPF 方式”，而不是仅仅将您的 WinForms 方式融入其中。这是一种不同的编码方式。
【讨论】：
2016 年的观点：
我不经常提倡对这么老的问题发表意见，但我认为在这个问题上写一个结尾可能是合适的。为什么？因为即使是现在（2016 年），我听到企业环境中的开发人员仍然问这个问题。
是的，七年后，WinForms 仍然存在于企业环境中，并且仍然受到 Microsoft 的支持。 Google Trends 显示出自 2005 年年中以来的兴趣缓慢而稳定地下降，目前的兴趣约为 2005 年的三分之一。
WPF 在 2009 年引起轰动，但从未完全成为新 UI 开发的事实标准。谷歌趋势显示 WPF 的兴趣在 2009-2011 年达到顶峰，然后比 WinForms 下降得更快。当前的搜索兴趣约为 2011 年的一半，但仍是 WinForms 当前搜索兴趣的近两倍。
那么开发人员现在在使用什么？基于 Web 的 UI 已经流行起来，主要是由于移动浏览的兴起。您可能会争论编写 Web UI 的最佳方式（AngularJS + WebAPI？ASP.NET MVC？React？所有这些都在 Google Trends 上呈上升趋势）。无论您使用哪种技术，都很难否认编写一次（响应式）UI 并让它在几乎所有设备和平台上运行的吸引力。云托管服务通过提供几乎即时/无限的扩展和较低的前期基础设施投资，进一步推动了网络发展。
所以今天，我衷心推荐转向 Web UI，因为它可能会延长您的应用程序的保质期 - 这通常需要在企业环境中持续很长时间。或者，如果您是从事移动开发的 Microsoft 开发人员，Xamarin 值得一看。
【讨论】：
WinForms 可能会在企业环境中出现很长时间。它们可以很好地用于许多目的。许多项目都基于 WinForms，许多公司会在项目期间坚持使用该技术，而不是混合搭配。
话虽如此，WPF 就是未来。这是一种更高效、更强大的 UI 技术，非常值得学习。
WinForms 和 WPF 可以共存于一个应用程序中。这可能是他们被介绍给公司（以及小型概念验证项目）的最常见方式。
【讨论】：
当然不会。
Winforms 更易于使用（考虑到您还不了解 WPF），而且 WPF 与 Winforms 模型完全不同。
如果您想要一个简单的 GUI（标准格式的东西），请使用 Winforms。如果您想要一些更华丽的东西并且有时间，请选择 WPF。
我相信将来 WPF 会成为事实上的标准。但就目前而言，如果我想要快速干净的东西，我会坚持使用 Winforms。
值得一提的是，很多应用程序已经在使用 Winforms - 这意味着维护工作经常会涉及到 WinForms，所以暂时不要把它搞砸。
【讨论】：
WinForms 没有死。谷歌“winforms C# jobs”，你会发现很多。 WPF 是热门的东西，但它仍然相对较新。恕我直言，再过两到三年它就不会成为主流。
【讨论】：
这是一个很好的blog post 关于 WinForms 和 WPF。总体思路是明智地选择，这意味着没有一个胜过另一个。每个都有不同的功能子集。
然而，在 WPF 和 WinForms 之间做出决定是另一回事。当然，WPF 是新的热点，而 WinForms 又老又破，但它是正确的选择吗？显然，“这取决于”情况，Microsoft 将继续提供和支持 WinForms，因此它不会很快消失。那么选择 WPF 而不是 WinForms 的令人信服的因素是什么？ Karl 在他的 WPF 业务应用程序系列中暗示了 WPF 而不是 WinForms 的选择，但对某些人来说原因可能很微妙。
我个人更喜欢 WPF，因为我最初是一名 Web 开发人员，发现标记 XAML 更自然。
【讨论】：
我认为在 WPF 成为主流之前绝对值得学习它，提高你的技能总是好的，拥有新技术的经验和知识总是一个加分项，特别是如果 WPF 将来要得到更广泛的应用。
此外，虽然编写 xaml 标记与创建表单有很大不同，但它距离编写 html 并没有一百万英里，如果您做过任何 Web 开发，对您来说可能不会有太大的不同。
虽然 WinForms 是一项较旧的技术，但这并不意味着它会永远消失，但我工作的应用程序仍然是用 VB6 编写的。我们的开发部门只有一半使用 .NET - 我们分为 3 个团队，一个团队仍在使用 .NET 1.1，另一个团队正在使用 .NET 2，而我所在的团队正在使用 .NET 3.5（你可以说我们是幸运儿！）
【讨论】：
我们开始在一个新项目中使用 WPF，坦率地说，很难回到 WinForms。很多整洁的东西，我再也离不开了。
不过还是要提个建议。即使您可以使用 WPF 进行更复杂的布局（就像提到的那样，按钮或几乎任何东西都可以承载其他东西，如图像、文本框等等），但在 WinForm 中找到的其他一些“基本”东西很难重现. 示例：在 WPF 工具包出现之前，WPF 没有数据网格和日期时间选择器，因此您必须自己做。另外，它仍然没有MaskTextBox，您必须自己做或从第三方下载。我遇到的最后一个我实际上发现注释的是 Treeview ：叶子和父母之间的线条没有显示。
话虽如此，在大多数方面还是比 WinForm 好很多。
【讨论】：
我们开始在一个新项目中使用 wpf
新应用程序在 winforms 中包含大量遗留代码。
只要我们想使用旧的 winforms 对话框，它都是可能的。
当您使用 WPF 时，您并不想回到 winforms。做 GUI 的东西要容易得多，这些东西会花你很多时间在 winforms 中。
任何方式都需要一些时间来学习这些东西并能够使用它的所有功能（不仅仅是 UI，还有数据绑定和命令模式）。
让有经验的人帮助第一个架构会很有帮助。
【讨论】：