创建新的 GUI 时，WPF 是否 Windows 窗体的首选？ [关闭]

Posted 2023-02-22

【中文标题】创建新的 GUI 时，WPF 是否 Windows 窗体的首选？ [关闭]

【英文标题】：When creating a new GUI, is WPF the preferred choice over Windows Forms? [closed]创建新的 GUI 时，WPF 是不是 Windows 窗体的首选？ [关闭]

【发布时间】：2010-09-08 15:29:04

【问题描述】：

Windows 窗体的大多数限制和技巧对于大多数程序员来说都是常见的。但由于 .NET 3.0 也有 WPF 可用，即 Windows Presentation Foundation。据说您可以使用它更轻松地制作“性感应用程序”，并且使用 .NET 3.5 SP1 可以大大提高执行速度。

但另一方面，许多事情与 WPF 不同。我不会说它更难，但你必须从头开始学习“一切”。

我的问题：当您必须创建一个新的 GUI 并且项目没有时间压力时，是否值得花费这些额外的时间？

【问题讨论】：

WPF 和 Winforms 有性能差异吗？

是的，有 tim，Winforms 几乎可以处理任何事情。

@Camilo：我认为您的评论具有误导性。在大多数情况下，Winforms 的速度大约是 WPF 的 1.2 倍。对于一些事情，它的速度是原来的 2 倍。另一方面，在很多方面，WPF 实际上比 Winforms 快，有时甚至快得多（例如，动画在 WPF 中的速度很容易达到 10 倍）。但我不知道 Winforms 比 WPF“快得多”的任何东西。

@Ray 这取决于你的显卡。为常用控件渲染矢量图总是比在屏幕上显示位图要慢。至少我已经看到虚拟机上的一些 WPF 应用程序的性能显着下降（因为虚拟机没有使用显卡），但我也可能错了。它的好处是，由于抽象，WPF 对开发人员更好（一旦有人学习它，我正在学习它）。另外，CPU 每天都在变得越来越快（或者至少对于多线程代码而言）。

任何组件套件（例如 DevExpress）在其 WinForms 化身中都比 WPF 更快。包括重绘、响应能力和内存要求。

【参考方案1】：

在尝试在 WPF 上敲定一个 line-of-business (LOB) 应用程序三个月后，我开始考虑为我的项目返回 Windows 窗体，并且在研究其他人的意见时，遇到了这个线程。 .

是的，WPF 是一项出色的技术，它所带来的好处远远超出了单纯的吸引眼球……模板和绑定功能就是很好的例子。整个对象模型提供了更大的灵活性和更广泛的可能性。然而，这并不能使它成为未来 LOB 应用程序的实际平台。

WPF 在将 GUI 与业务逻辑分离方面解决的“问题”并不是在 Windows 窗体中通过简单地从正确的体系结构和思维方式开始即可轻松解决的问题。甚至 WPF 的对象路径绑定功能也可以通过一些非常简单的帮助类在 Windows 窗体中重现。 WPF 的数据模板功能非常好，但在极少数情况下，当您完全不知道要在任何给定部分上表示哪些对象时，它们又不是您无法在 Windows 窗体中模拟的。屏幕。

Windows 窗体领先的地方在于成熟度。如果不访问某人为您解决了 Windows 窗体问题的博客，您就无法在 Google 上挥动一只死猫。另一方面，WPF 的可用学习资源相对较少，可用的自定义控件较少，而且还没有解决很多初期问题。

在做出 WPF 与 Windows 窗体的决定时，必须考虑开发环境的成熟度。 Windows 窗体编辑器流畅、响应迅速且直观。有关错误的反馈会立即发送给您，解决方案通常很明显，并且 Windows 窗体中的编译->调试->编辑周期非常快。

另一方面，WPF 应用程序具有相对可怜的设计时间支持，设计视图在第一次遇到错误时已经准备好退出，通常需要在设计人员愿意之前在修复之后构建项目重新开始。考虑到在很多情况下它要么根本不起作用，要么产生完全不直观的结果，因此也可能不支持从工具箱中拖放组件。尽管有 WpfToolkit 的承诺，但仍然没有用于 WPF 的可用 DataGrid 产生任何类型的合理性能或设计时间友好性。

调试 WPF 应用程序有点像 旧 ASP.NET 调试范例...点击 F5 -> 等待 -> 启动 -> 错误 -> 停止 ->修复 -> 点击 F5 -> 等待 -> 启动 -> 错误 -> 呻吟 -> 停止 -> 修复 -> 点击 F5.... 您的程序的所有 XAML正在运行被锁定，跟踪 XAML 特定问题通常很乏味。

简而言之，Windows 窗体的开发工具将让您在 WPF 应用程序的一小部分时间内完成前端...尤其是如果您正在创建大多数 LOB 都有的主从网格或类似界面的电子表格。使用 Windows 窗体，您可以从已经为您完成的 90% 的工作开始。

我是 WPF 架构的忠实粉丝。我只是希望设计时工具集不像是 pre-alpha 调试版本。

---

编辑：此答案是关于 .NET 3.5 + Visual Studio 2008 发布的，但带有 Visual Studio 2010 的 .NET 4.0 附带 WPF 数据网格。虽然对新的 WPF 开发体验进行了许多改进，但我这里的回答没有改变，我想补充以下建议：

如果您急于进行RAD 开发，请使用 Windows 窗体。如果您正在寻找构建良好、可维护、可扩展、资源友好、多用户的业务线应用程序，请考虑使用 ASP.NET MVC + html 5 + jQuery ......我使用这些技术的项目带来了更好的结果为我的客户带来更快的结果。 MVC 提供了与 WPF 相同的模板，而 jQuery 支持动画和复杂的交互。更重要的是，ASP.NET MVC + jQuery 解决方案不要求您的最终用户拥有具有良好图形硬件的现代桌面。

【讨论】：

+1 完全同意，很高兴听到有人在现实世界中实际尝试过技术并承受现实压力。当工具和开发人员终于赶上时，WPF 可能会在 5 年内表现出色。即便如此，WinForms 仍然存在。

DataGrid 控件支持 WPF 3.5 SP1 中的列虚拟化。这应该可以解决它的性能问题。

过去我做过很多 ASP3 和 ASP.NET，我很高兴能够使用 XAML 设计我的 UI。我在输入 xaml 时看到了 UI（在我的脑海中），对我来说它比 UI 设计师快得多......但是我是开发人员而不是设计师，所以这可能会解释一下

您使用的是 Expression Blend 还是 VS.NET？ VS.NET 有你提到的所有问题，但 Expression Blend 是 WPF 应用程序设计和布局的绝佳工具。它对于 WPF 开发至少与 VS.NET 对于 WinForms 开发一样好：我会说它要好得多。早在 WPF 的早期，这些工具并不是那么好，但 Expression Blend 2 解决了您提到的所有问题。 XAML 在任何时候都是完全可编辑的，我从未遇到过崩溃或因错误而“退出”的情况。 Master-Detail 实际上内置于 CollectionView 和“/”功能中。

【参考方案2】：

我已经使用 WPF 七个月了，现在它已成为我的客户的核心系统，我想与您分享一些关于学习和使用 WPF 作为业务线演示平台的经验的想法.

总的来说，我上面制作的 cmets 仍然适用... WPF 的设计时支持还没有出现。如果您急于推出富客户端应用程序，请使用 Windows 窗体。时期。 Microsoft 并不急于停止 GDI / Windows Forms 平台，因此您可以在未来一段时间内获得良好的支持。

WPF 并不容易掌握，但这不应该是您决定是否投入时间和精力学习 WPF 的地方。尽管 WPF 目前还不够成熟，但它是围绕一些有用的现代概念构建的。

例如，在 WPF 中，您对编写良好且具有健全验证逻辑的业务对象的投资是一项可靠的投资。与 Windows 窗体不同，WPF 的数据绑定充满了允许界面控件对无效用户输入做出反应的功能无需编写 GUI 代码来检测这些错误。这很有价值。

事实证明，WPF 中的样式和模板功能也很有价值。尽管人们普遍认为样式和模板的唯一用途是创建屏幕上的视觉效果，但事实是，这些功能显着简化了提供丰富反馈的用户界面的编码 - 例如禁用/启用自身的按钮底层业务逻辑层的状态，或根据光标下对象的状态智能查找其文本的工具提示等。

所有这些都为“没什么花哨的”业务应用程序提供了非常有价值的功能，仅仅是因为它们可以很容易地使界面与底层数据保持一致。

简而言之：

在 Windows 窗体中，您设计您的用户 接口，然后编写代码驱动 该用户界面，通常 还包括驱动您的代码 数据对象。 在 WPF 中，您投资于驱动数据对象的业务层，然后设计一个侦听数据对象的接口。

这似乎是一个微妙的差异，但它对您重用代码的能力产生了巨大的影响......这就引出了一个问题：“Windows 窗体与 WPF 的问题实际上是一个投资决策吗？”

（这似乎已成为我最喜欢的线程。）

【讨论】：

当您执行第一个 WPF 应用程序时，这确实是一项投资。我猜大多数由前 WinForms 程序员完成和估计的第一个 WPF 项目都会迟到。在我看来，学习 WPF 是非常值得的，但问题是你的雇主是否也这么想……

【参考方案3】：

是否有任何令人信服的理由使用 WPF

绝对！ WPF 绝对令人难以置信！这对于几乎任何项目来说都是一个主要的好处，因为它具有许多 Windows 窗体所缺乏的特性和能力。

对于商业应用程序，最大的胜利将是：

出色的数据绑定和模板是最大的不同。一旦一个体面的数据模型到位，只需单击几下即可创建数据模板并使用Expression Blend 使用拖放操作准确配置对象的外观。绑定到颜色或形状之类的东西是微不足道的。 屏幕布局非常灵活。 WPF 中的所有内容不仅可以平滑地适应容器大小和形状的变化，而且可以轻松地放大和旋转项目，甚至可以延伸到其包含框架之外。 普通对象可以以任何您喜欢的方式呈现，可以轻松地在不同的屏幕上进行不同的呈现，可以共享呈现，并且可以使它们的呈现适应数据值的变化。 如果您需要打印，渲染到打印机是很简单的。如果配置正确，WPF 会使 Crystal Reports 或 SQL Server Reporting Services (s-s-rS) 看起来像孩子的玩具。 您的用户界面的外观和感觉都将更加动态，包括一些不错的功能，例如当您将鼠标移过按钮时会产生动画效果。

对于实用程序和游戏，其他优势尤为突出：

您可以轻松地将形状、线条和任意绘图添加到您的应用程序中，而无需使用外部编辑器。这些组件的每个组件都可以是数据绑定和动画的，或者由代码控制。在 Windows 窗体中，您通常只需要导入位图并按原样使用它，除非您想进行大量工作。 动画很酷！只要您不过度使用它，用户就会真正印象深刻。它们还可以帮助人们了解正在发生的事情并减少对突出显示的需求。例如，当拖动一个对象时，您可以为目标设置动画，以显示如果您放下它会发生什么。 颜色、渐变填充、画笔、花哨的字体、任何对象的旋转、瓷砖画笔等。您想要的任何图形都可以随叫随到。 令人难以置信的可定制性。我需要为一个应用程序绘制铁轨，这样我就可以在上面放一列火车。几个小时后，我有了可以使用Bézier curves 在屏幕上任意位置绘制的铁轨，它们会自动加入并切换。

最重要的是，您可以在 Windows 窗体中构建的任何大型 GUI 都可以在 WPF 中构建，只需三分之一（或更少）的工作量，并且看起来更好。

WPF 是否需要更多资源（尤其是 RAM）

与 Windows 窗体相比，您确实付出了一些代价，但代价很小。

RAM 可以根据您的实施而上升或下降。 WPF 更有效地存储其数据，因此单个对象更小，但 WPF 中的对象往往比 Windows 窗体中的更多，因此这是平衡的，任何一个都可以领先。 与 Windows 窗体相比，CPU 会上升。根据我的经验，屏幕上 WPF 对象的实际更新占用的 CPU 大约是普通 Windows 窗体渲染的两倍。如果您的应用程序大部分时间都在更新屏幕，那么 WPF 可能不适合您。但在这种情况下，您可能也没有使用 Windows 窗体：大多数严肃游戏都直接写入 DirectX。 WPF 的磁盘使用量会稍微少一些，因为它使用的代码比 Windows 窗体少得多。当然，数据大小相同。

关于 CPU 使用的另一个注意事项：动画和变换（运动、平移等）实际上在 WPF 上比在 Windows 窗体中更有效，因为它具有保留模式存储。物体最初的获取速度较慢。

维护开销

在维护方面，WPF 是对 Windows 窗体的巨大胜利。由于一切都是用以前的 1/5 代码完成的，因此需要维护的代码也只有 1/5。此外，所有样板文件都消失了，因此您可以专注于实际完成工作的代码。

XAML 的好处

XAML 是 WPF 的核心。尽管 WPF 可以在没有 XAML 的情况下使用，但 XAML 使其非常易于使用。 XAML 具有 HTML 轻松指定用户界面的能力，但其内置标签功能更强大，您可以轻松定义自己的标签。 （其实这样做也很正常）。

XAML 的一些特定优势：

您的整个 UI 都定义在一个文本文件中，对于用户和工具而言，该文件易于阅读和操作 MarkupExtensions 允许以清晰简单的方式指定绑定 类型转换器允许轻松指定具有复杂类型的属性。例如，您可以说 Brush="Green" 或者您可以指定具有三个停止点的径向渐变画笔。 您可以创建自己的元素 您可以轻松利用 WPF 强大的“附加属性”

其他见解

多年来，我一直梦想着像 WPF 这样的东西。许多人已经实现了此功能的一部分，但以这样的价格（0 美元）将所有功能集中在一个地方，真是太棒了。

WPF 是从 Windows 窗体的巨大范式转变，需要一些时间来适应，但花在学习上的时间将获得多倍的回报。

即使五年后，WPF 仍然有一些缺点，但一旦你体验过它的威力，它的威力会让你大吃一惊。如果有人试图将您拖回 Windows 窗体，您只会大喊大叫。

提示： - 获取 Expression Blend 的副本以进行开发 - 偶尔手动编辑 XAML - 起初看起来很奇怪时不要放弃

【讨论】：

»包括一些不错的功能，例如当您将鼠标移到按钮上时会显示动画的按钮«您的意思是，就像 Windows 已经对任何普通按钮所做的那样？

@Johannes：不，我没有。 Windows 所做的只是在按钮上加一个亮点（即使它是一个普通的按钮也有效）。 WPF 可以做得更多。例如，一个按钮可能有一个门图标，当您将鼠标悬停在它上面时它会铰链打开，或者插入指针可能会出现在 UI 的其他位置。这种额外的丰富性在业务应用程序中非常有用，因为它提高了用户的工作效率。

【参考方案4】：

WPF 使您能够做一些令人惊奇的事情，我喜欢它......但每当开发人员问我是否认为他们应该转向新技术时，我总是觉得有义务证明我的建议。

您的开发人员是否愿意（最好是 EAGER）花时间学习有效地使用 WPF？我从没想过要对 MFC、Windows 窗体甚至非托管 DirectX 这么说，但您可能不希望团队在正常开发过程中尝试“拿起”WPF。运输产品的周期！

您的至少一两个开发人员是否具有一定的设计敏感性，并且具有最终设计权限的个人是否对开发问题有良好的理解，因此您可以利用 WPF 功能来创建实际上更好的东西，而不仅仅是更多“多彩”，以免费动画为特色？

您的目标客户群中是否有一部分运行在可能不支持您计划的功能的集成图形芯片组上——或者他们仍在运行 Windows 2000，这将完全排除他们作为客户的身份？有些人还会问您的客户是否真的关心增强的视觉效果，但是在经历了 90 年代初期公司内部“我们的业务客户不关心颜色和图片”的辩论后，我知道您的竞争对手精心设计的解决方案会让他们关心，真正的问题是条件是否合适，使您能够提供让他们现在关心的东西。

该项目是否涉及基础开发，至少对于表示层，以避免尝试挂钩到不兼容的旧式脚手架的额外复杂性（与 Win Forms 的互操作不是无缝的）？

您的经理能否接受（或分心）开发人员生产力在四到六个月内的显着下降？

最后一个问题是由于我喜欢将 WPF 视为“FizzBin”性质，有十种不同的方法来实现任何任务，没有明显的理由偏爱一种方法而不是另一种方法，几乎​​没有可提供帮助的指导你做出选择。不仅您所做的任何选择的缺点只会在项目的后期才变得清晰，而且您几乎可以保证项目中的每个开发人员都采用不同的方法，从而导致严重的维护问题。最令人沮丧的是，当您尝试学习该框架时，经常会遇到不一致的问题。

您可以在我的博客上的一篇文章中找到更深入的 WPF 相关信息：

http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx

【讨论】：

我喜欢您指出集成图形芯片问题的事实。这不止一次地折磨着我们。痛，哦，痛。

我也喜欢你指出你所说的 WPF 的“FizzBin”性质。确实有很多方法可以做事情，很难知道（尤其是当你刚刚开始时）哪种方法是最好的方法。如果我能给你两个大拇指，我会的。很好的答案。

【参考方案5】：

WPF 需要 Windows Vista 或 Windows XP SP2，这不是一项繁重的要求，但却是一个相关的要求。如果您想在 Windows 2000 上运行（有些人仍然这样做），那么 WPF 将不适合您。

WPF 也是一种较新的技术，并且不如 Windows 窗体经过验证，因此您可以选择 Windows 窗体作为风险较小的选项，尤其是对于较大的应用程序。

话虽如此，是的，WPF 是未来。 Visual Studio 2010 正在用 WPF 重写，这可能是迄今为止最大的 WPF 应用程序，它也将是对该技术的真正考验。

显然，旧的 Windows 窗体应用程序将是另一种情况，它是正确的选择。

【讨论】：

你有那个 VS2010 信息的链接吗？

只是 google for Visual Studio 2010 Wpf 一些例子：demiliani.com/blog/archive/2008/10/28/6520.aspxayende.com/Blog/archive/2008/10/27/visual-studio-2010.aspx

那么我认为最好等到 MS 完成此操作、吸取教训、修复所有小问题并添加所有需要的扩展以使其正常工作。

如果您查看 Rico Mariani 的博客，您会发现他们已经向 WPF 团队报告了许多错误、泄漏和性能问题。让 VS 大量使用 WPF 是 WPF、IMO 的一大进步。

顺便说一句，Windows 2000 刚刚变得不受支持（敲响了过时的钟声）：support.microsoft.com/ph/1131

【参考方案6】：

正如其他人所说，无论你走到这里，都有优点和缺点。正如其他人所说，WPF 的优点包括：

能够相对轻松地制作非常丰富的 UI。 更简单的动画和特效 固有的可扩展性（在 WPF 应用程序和 Windows 窗体应用程序上使用 Windows Vista 放大镜工具：请注意，在 WPF 应用程序中，所有矢量图都可以很好地缩放） （OPINION ALERT）我觉得在 WPF 中做面向文档的系统“更容易”

但是，WPF 也有一些缺点，Windows 窗体在其中占据优势：

WPF 的内置控件套件远比 Windows 窗体受限。 Windows 窗体的第三方控件空间提供了更多支持。 （当然，这种情况正在发生变化，但请想一想：Windows 窗体自 2001 年以来就已经存在；WPF 仅仅几年。由于时间的推移，Windows 窗体在社区中得到了更多的支持。） 大多数开发人员已经知道 Windows 窗体； WPF 提供了新的学习曲线

最后，请记住，如果您完成工作（或使用正确的第三方工具），您可以在任一工具中创建出色、有吸引力和引人入胜的 UI。归根结底，在所有情况下，两者都不一定更好。使用适合该项目的方式。

【讨论】：

您关于“WPF 的内置控件套件远比 WinForms 受限”的说法可能会被误解。 WPF 的内置控件套件比 WinForms 可以做的远远更多，因为每个控件都可以模板化并且具有多种用途。 WinForms 中的几乎所有内容都直接映射到简单的 WPF。但是，在最初的 WPF 版本（NET Framework 3.0）中，缺少 WinForms 内置的三个函数：DateTimePicker、NumericUpDown、DataGrid。这三个都很容易下载，而且最新的 WPF (3.5 SP1) 在包中添加了一个 DataGrid。

此外，还有一些单独的 WinForms 控件不存在的功能，例如 TextBoxes 的 AutoComplete。到这个时候（2009 年 11 月），所有这些的简单解决方案已经发布在博客上。因此，不再有任何理由选择 WinForms，因为 WPF 缺少任何控件。如果 WPF 缺少您需要的供应商提供的控件，您仍然可以为该控件使用 WinForms 集成。

对我来说，WPF 的最大优势在于它的数据绑定、模板和布局。

“想想看：WinForms 自 2001 年就已经存在”：是的，但 WinForms 自 .NET 2.0 以来就没有发展......

明白答案是什么时候写的……一年多以前，这一切都是真的。现在，是的，我可能会立即使用 WPF。 :)

【参考方案7】：

WPF 的编程模型比 Windows 窗体更开放和灵活，但与 ASP.NET MVC 一样，它在正确实现模型-视图-视图模型模式方面需要更多的纪律。

我的第一个带有 WPF 的 LOB 应用程序最终以彻底失败告终，因为它是一种资源消耗，导致我的最终用户的超低端笔记本电脑停止运转......这最终是因为我只是加入 WPF + LINQ to SQL 并期待一个好的结果......这就是 WPF 与 Windows 窗体如此强烈不同的地方......在 Windows 窗体中，你可以摆脱这种事情。 WPF 在资源上比 Windows 窗体要重得多，如果您不将应用程序设计为精简，您最终会得到一个 800 磅的大猩猩。

不要回避 WPF... 探索它。但请注意，Windows 窗体编码可接受的错误不会在 WPF 中产生良好的结果。它们是根本不同的引擎，它们适用于根本不同的编码模式。

最后一句话：如果您继续使用 WPF，请熟悉用于列表和网格的数据虚拟化。什么是简单的数据绑定 ListItem 或 GridCell 最终会成为 WPF 中庞大的逻辑 + 可视对象图，如果您不学习如何虚​​拟化，您的应用程序将无法在大型数据集上表现良好。

【讨论】：

感谢您回来，重温这里并分享您的经验。我很感激。

我也有同样的经历。不幸的是，我还没有找到关于如何使用 WPF 真正实现这样一个 LOB 应用程序的足够精确信息。

【参考方案8】：

WPF 有一个非常陡峭的学习曲线，我建议您首先获得显而易见的书籍 (Adam Nathan, Sells/Griffiths，和 Chris Anderson) 和 博客（Josh Smith 等）。只需为此做好准备，并确保您的项目允许您有时间学习 WPF。

除了学习技术之外，还要花一些时间学习用于构建 WPF 应用程序的模式。 Model View ViewModel (MVVM) 似乎获得了广泛的认可。

就个人而言，我认为 WPF 是值得的，但要预先警告。另请注意，您有效地将用户限制为 Windows XP SP2+ 和 Windows Vista。我们已经做出了这个决定，但您可能有一些不同的要求。

【参考方案9】：

这两种技术各有利弊。在具有“经典” UI 的大型应用程序中，我会使用 Windows 窗体。在需要丰富用户界面（皮肤、动画、更改用户界面）的应用程序中，我会选择 WPF。请查看文章WPF vs. Windows Forms比较 WPF 和 Windows 窗体。

【讨论】：

+1 链接。 Josh 在成功开发 WPF 项目（包括 NY Times Reader）方面拥有丰富的实际经验。

【参考方案10】：

除了 UI 设计的灵活性之外，WPF 还有一些技术优势：

1.) WPF 不依赖 GDI 对象。嗯，我认为它使用 2 个 GDI 对象作为窗口本身的实例，但这实际上没什么。我在一定程度上参与了一个非常大的内部 Windows 窗体应用程序。我们办公室的人有时会同时运行 3 或 4 个实例。问题是它们经常遇到 Windows 2000、XP 和 Vista 固有的 10,000 个 GDI 对象限制。发生这种情况时，整个操作系统变得无响应，您将开始看到视觉伪影。清除它的唯一方法是关闭应用程序。

2.) WPF 利用 GPU。 WPF 将部分 UI 处理卸载到 GPU 的能力非常出色。我只希望它的这方面随着时间的推移会变得更好。作为前 OpenGL 编程爱好者，我可以体会到来自 GPU 的力量。我的意思是，我 100 美元的显卡有 112 个内核，每个内核运行频率为 1.5 GHz（无论如何这都不是***的）。这种并行处理能力足以让任何四核 CPU 相形见绌。

但是，WPF 仍然很新。它不能在 Windows 2000 上运行。事实上，WPF 应用程序在重新启动后启动速度可能很慢。我在我的博客上讨论了所有这些： http://blog.bucketsoft.com/2009/05/wpf-is-like-fat-super-hero.html

【讨论】：

+1 以补充设计方面的技术视角。

出于兴趣，GDI+ 对这些点有任何影响吗？

嗨史蒂夫。很重要的一点，虽然我在 GPU 问题上遇到了麻烦，但在发现我的应用程序的许多用户正在运行带有英特尔“假”GPU 芯片的笔记本电脑后，这会无休止地损害 WPF 性能。

@JBR - 我不确定 GDI+。 @Mark - 我知道你的意思，其中一些集成芯片很糟糕。

【参考方案11】：

我觉得WPF值得学习。一旦您加快速度，恕我直言，您的表单设计工作会容易得多。我不会那么担心“性感”的东西。这大部分只是一种时尚。您可以在 WPF 中快速轻松地制作“普通”Winforms 风格的应用程序。

整个概念使 IMO 设计更容易。

【讨论】：

我同意 Rich 的观点。 WPF 的性感已经被过分强调了。我认为这是一项很棒的技术，它提供了一些非常有说服力的论据来使用它……用于标准的、普通的业务应用程序。

【参考方案12】：

我不同意这里的一些答案。 WPF 非常适合line of business (LOB) 应用程序。 （青蛙设计 LOB 客户端就是最好的例子）。除了让您的 UI 变得引人注目（这在业务应用程序中不是必需的）的所有可能性之外，WPF 还为您提供了更多。

数据绑定和模板功能仅优于 Windows 窗体。它还提供了一种更好的方法来分离代码和表示。 我们在不超过 2-3 名开发人员的团队中成功地将 WPF 用于 2 个 LOB 应用程序。

您将面临的最大问题可能是 WPF 的陡峭学习曲线（与 Windows 窗体相比）这将降低不习惯 WPF 的开发人员的开发速度。

【讨论】：

我不得不同意...学习曲线很陡峭，但从长远来看肯定会有所回报。我从 WPF 开始，从未回头。

【参考方案13】：

我们目前正在 WPF 中从 Windows 窗体重写我们的应用程序。是的，有一个陡峭的学习曲线，你必须“重新学习”一些东西，但这是非常值得的。结合 WCF，我们发现我们编写的代码比以往任何时候都更少、更快、更健壮。

坚持一段时间，阅读Adam Nathan's book，并查看不断增长的第三方控件库，例如来自Telerik 和ComponentOne 的那些。在我看来，一个负面因素是设计工具Expression Blend 使用起来非常尴尬。最新版本仍处于测试阶段，但对于我们这些使用 Visual Studio 多年的人来说，它只是感觉不对劲。是的，它主要面向设计师，但有些事情在 Visual Studio 中是做不到的。

【讨论】：

是的，“编写更少的代码、更快、更健壮”是描述 WPF 体验的好方法。这根本不是眼睛糖果。顺便说一句，自从编写了 Expression Blend 以来，Expression Blend 已经发布，已经到了第 3 版，并且使用起来非常流畅 - 比任何 VS.NET 设计器都要好。

本书有新版本amazon.com/WPF-4-Unleashed-Adam-Nathan/dp/0672331195

【参考方案14】：

如果界面设计对您很重要，请考虑使用 WPF，因为 WPF 可以提供更好的 UI 体验。但 Windows Forms 拥有多年的演变，因此它被证明是有效的，并且您可以找到许多精通该平台的程序员。

移植性也可能是个问题，WPF 仅适用于 Windows XP SP2 及更高版本。

此外，WPF 具有陡峭的学习曲线，这意味着如果没有特定的 WPF 经验，要交付高质量的产品并不容易。

【参考方案15】：

嗯，一个答案是“当您必须支持 1.1 或 2.0 时”，因为 WPF 是 .NET 3.0 的一部分。 WPF 存在已知的操作系统限制，并且存在一个明显的技能问题：如果您有一个了解 winforms 的开发人员团队，那么使用 winforms 生成健壮的代码可能会更容易。但是，如果您正在编写大量 UI 代码，则可能值得在某个时候开始使用 WPF。

WPF 还与 Silverlight 有很多共同点，因此它具有可转移的优势。

【参考方案16】：

WPF 具有许多优点，例如出色的数据绑定功能， 关注点分离，设计和逻辑分离等......

作为一名开发人员，我喜欢使用 XAML 来定义我的 UI，而不是 与 Windows 窗体设计器绑定在一起，知道自己能数数我感觉很好 让我的应用看起来不错。

我个人不在乎不支持旧版本的 Windows， 但 WPF 的一大问题是它不受（当前/永远）支持 由 Mono (http://www.mono-project.com) 提供，因此 WPF 应用程序将无法在 Mac OS 或 Linux 上运行。 （尽管 Silverlight 应用程序会）。

如果您有时间和资源投入学习 WPF，那就去做吧！ 即使您要编写 Silverlight 应用程序来支持多个操作系统。

如果您需要桌面应用程序在多个操作系统上运行，请使用 SWF。

【讨论】：

“WPF 具有许多优点，例如出色的数据绑定功能、关注点分离、设计和逻辑分离等......”同意。 WPF 提供的不仅仅是花哨的外观。它提供了更好的架构选择。

这是我最大的分歧。我正在升级到我的一个应用程序的“2.0”，虽然我对 WPF 的所有初始实验都非常棒，但我确实希望该应用程序是跨平台的，所以我将使用 Winforms 来利用 Mono 进行 2.0。这不会阻止我在 WPF 中重写我的其他应用程序

【参考方案17】：

有很多不同之处。我们喜欢 WPF 的原因是：

声明式编程风格。 动画和状态转换 Expression Blend 是一个很棒的工具 良好的风格支持。

但是，我们坚持使用 Windows 窗体是因为：

开发人员在学习 WPF 时 已经了解 Windows 窗体。 WPF 将无法在 Windows 2000 或 更低。

【讨论】：

Windows 2000 有那么重要吗？我的意思是，有多少人被困在那个考古操作系统中？

这是因为微软正在为旧笔记本电脑和个人电脑赞助一些特殊的学校版本（Windows 2k）——我认为该项目的名称是 FreshStart...

是的，至少是WinXP……Win2000？！来吧！

@cevik，Fresh Start 似乎已于 2009 年去世。microsoft.com/Education/Freshstart/FsSplash.aspx

@dangph，不幸的是，这是真的，我希望他们可能会从 XP 开始 :)

【参考方案18】：

在决定使用哪一个时，最大的考虑是考虑您的目标受众安装了什么 .NET Framework。我发现更多人使用仅支持 Windows 窗体的较低 .NET Framework 版本，但这只是我的个人经验。

【讨论】：

2009 年 11 月，20-50% 的计算机已经安装了 NET Framework 3.0 或更高版本，因此它们已经可以运行 WPF。对于那些不这样做的人，您可以将它包含在您的 CD 中，或者让您的应用程序在安装时下载 NET Framework 客户端配置文件。在 256K DSL 线路上下载客户端配置文件需要 2 分钟，您可以通过将其设置为从 Microsoft 网站下载来节省带宽。

【参考方案19】：

WPF 的优点是使用自定义控件和动画创建漂亮的 GUI 更加容易。 WPF 还有助于进一步分离表示层和逻辑层。如果您有设计师，它可以让您将 95% 的工作交给非编码人员，并允许编码人员从事逻辑工作。缺点是 Expressions Blend 的软件成本，以及缺乏任何运行良好的 Visual Studio 代码分析工具，因为它们往往会在尝试呈现 XAML 时陷入框架调用。我敢肯定还有其他人，但这是我们真正看到的仅有的两个。

主要考虑因素是如果您希望要求您的客户必须安装 .NET 3.0 甚至更好的 .NET 3.5 SP1。你会得到一些负面的反馈

【讨论】：

您可以将 NET Framework 包含在您的 CD 中，或者您可以将其设置为从 Microsoft 的网站下载 2 分钟（假设 256K DSL 线路）。无论哪种情况，它都可以作为应用程序安装的一部分进行安装。这也适用于 ClickOnce。

我有 2M DSL，整个安装过程通常需要半个小时，因为它不会在我的（通常是全新安装的）XP 机器上崩溃。

我的经验是在 XP 上安装 Client Profile (3.5 SP1) 大约需要 5 分钟，包括下载。到目前为止，它一直安装没有问题。关于可能会减慢您速度的一些想法：1.您正在安装完整的框架而不是客户端配置文件，2.您的 ISP 与 Microsoft 服务器的带宽很差且没有缓存，3.您的本地计算机正忙于执行 Windows 更新或其他软件更新，4. 您的本地带宽已饱和（例如通过流式传输音频/视频）。

也许我不够清楚。下载速度和不点击按钮对决定是否需要安装框架只有部分影响。最大的考虑是您的任何客户是否是企业或教育环境，本地用户可能无法选择安装它。

【参考方案20】：

WPF 使将表单设计工作交给真正的设计师而不是设计师服装的开发人员变得更加容易。如果这是您想做的事情，WPF 就是您的答案。如果经典的 Windows 样式按钮没问题，那么 Windows 窗体可能是要走的路。

（如果界面设计“对您很重要”，则多个答案声称您应该使用 WPF，但这很模糊。界面设计始终是“重要的”。）

【讨论】：

如果经典的 windows 样式按钮很好，并且您想花更多时间编写和调试管道，WinForms 可能是走。一旦掌握，WPF 的开发效率也比 WinForms 高得多，因为它具有丰富的数据绑定和数据模板、命令架构、附加属性等。即使您根本不关心视觉样式也是如此。

“设计师服装的开发者”——口袋保护套和高领毛衣？

【参考方案21】：

如果您有 MSDN 许可证，请查看 Expression tools。它专为 WPF 设计，直接导出到 Visual Studio，它可能有助于简化您的过渡。

【参考方案22】：

如果您只关心支持 Windows 并且不介意学习它所花费的时间，请选择 WPF。它快速、灵活、易于重新设计，并且有很好的工具来使用它。

【参考方案23】：

作为一个额外的好处，Silverlight 基于 WPF，从其中一个开始，您可以了解如何与另一个一起工作。如果事情继续基于 Web，那么拥有可以轻松传输到浏览器（或 Windows Live Mesh）的先验知识（和现有代码库）可能有助于让您的软件获得额外的生命。

【参考方案24】：

如果您决定使用 WPF，考虑到上述答案中已经解释的利弊，我强烈建议您通过 dnrTV episode with Billy Hollis

【讨论】：

我特别喜欢这个视频的前 25 分钟左右，Billy Hollis 展示了 WPF 和 WinForms 之间的一些功能差异。

【参考方案25】：

在DotNetRocks episode 315，Brian Noyes 对此进行了广泛讨论。

【参考方案26】：

WPF 中的文本呈现存在一个已知问题。许多用户报告说，大量使用抗锯齿和像素混合会导致文本模糊。在某些情况下，这是一个大问题，据我所知，微软在某种程度上已经承认了这一点。

【讨论】：

这已在 .NET 4 中修复——请参阅 blogs.msdn.com/text/archive/2009/08/24/…

【参考方案27】：

在过去的 3 1/2 年里，我一直在进行 Windows 窗体开发（在两家公司）。这两个应用程序都被广泛使用并最终遇到了 GDI 问题。大型 Windows 窗体应用程序最终将耗尽 GDI 资源 - 导致最终用户必须重新启动。

【参考方案28】：

Scott is complaining about Expression Blend 以及对他作为开发人员的意义。我对 Expression Blend 的第一反应就是这样。不过，现在我认为它是一个非常宝贵的工具，但这真的取决于你是什么类型的开发者。

我是一名用户界面开发人员，必须执行Integrator 角色，我最终发现Expression Blend 对于以所见即所得的方式创建样式和控制模板非常宝贵。我几乎总是同时在同一个项目上运行 Expression Blend 和 Visual Studio。

我还认为，在 Expression Blend 中玩耍并查看被吐出的 XAML 是学习 WPF API 的绝佳方式......就像在 Windows 窗体中使用设计器并检查 C# 代码一样它吐出有助于学习如何使用您在那里设计的任何东西。

Expression Blend 很有帮助。试一试，特别是如果您正在处理应用程序的视觉效果。

【参考方案29】：

引用an earlier post from Mark:

在 Windows 窗体中设计用户界面，然后编写代码来驱动该用户界面，这通常还包括驱动数据对象的代码。 在 WPF 中，您投资于驱动数据对象的业务层，然后设计一个接口来侦听您的数据对象。

我认为这更多是一种设计选择，而不是您使用的是 Windows 窗体还是 WPF。但是，我可以理解某些技术可能更适合特定方法。

【参考方案30】：

仅当您没有 WPF 专业知识并且不想投资时：)

【讨论】：

-1 鼓励人们认为不投资 WPF 实际上是一个有效的选择。

我想每个人都误解了我的回答，我说“你不想投资 WPF”并不意味着“不要投资 WPF。是吗？

我会留给 SO 用户来决定。