创建新的 GUI 时，WPF 是否是 Windows 窗体的首选？[关闭]
https://stackoverflow.com/questions/57909
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
Windows 窗体的大多数限制和技巧对于大多数程序员来说都是常见的。但自 .NET 3.0 以来，还提供了 WPF，即 Windows Presentation Foundation。据说，您可以使用它使“性感的应用程序”变得更加容易，并且使用.NET 3.5 SP1，它的执行速度得到了很好的提升。
但另一方面，WPF 中很多事情的工作方式都不同。我不会说这更困难，但你必须从头开始学习“一切”。
我的问题：当您必须创建新的 GUI 并且项目没有时间压力时，是否值得花费这些额外的时间？
解决方案
WPF 使您能够做一些令人惊奇的事情，我喜欢它......但每当开发人员问我是否认为他们应该转向新技术时，我总是觉得有义务验证我的建议。
您的开发人员是否愿意（最好是渴望）花时间来学习有效使用 WPF？我从来没想过要谈论 MFC、Windows 窗体，甚至非托管 DirectX，但您可能不希望团队在正常开发过程中尝试“学习”WPF。运输产品的周期！
您的至少一两个开发人员是否具有一定的设计敏感性，并且具有最终设计权限的个人是否对开发问题有充分的了解，以便您可以利用 WPF 功能来创建实际上更好的东西，而不仅仅是更“丰富多彩” ，以免费动画为特色？
您的目标客户群中是否有一定比例的运行在可能不支持您计划的功能的集成图形芯片组上，或者他们是否仍在运行 Windows 2000，这将完全消除他们的客户身份？有些人还会问您的客户是否真的关心增强的视觉效果，但是，经历过 90 年代初期公司内部“我们的商业客户不关心颜色和图片”的辩论后，我知道您的竞争对手精心设计的解决方案会让他们关心，真正的问题是条件是否合适，使你能够提供一些让他们现在关心的东西。
该项目是否涉及从头开始的开发，至少对于表示层来说，以避免尝试连接到不兼容的遗留脚手架而带来的额外复杂性（与 Win Forms 的互操作不是无缝的）？
您的经理能否接受（或忽视注意到）开发人员生产力在四到六个月内大幅下降？
最后一个问题是由于我认为 WPF 的“FizzBin”本质造成的，有十种不同的方法来实现任何任务，并且没有明显的理由更喜欢一种方法而不是另一种方法，并且几乎没有可用的指导来帮助您制定任务。选择。不仅您做出的任何选择的缺点只有在项目后期才会变得明显，而且几乎可以保证项目中的每个开发人员都采用不同的方法，从而导致严重的维护问题。最令人沮丧的是，当您尝试学习该框架时，不一致的情况会不断地困扰您。
您可以在我的博客上的一个条目中找到更深入的 WPF 相关信息：
其他提示
经过三个月的努力敲定 业务线 (LOB) WPF 上的应用程序，我考虑在我的项目中重新使用 Windows 窗体，并在研究其他人的意见时，遇到了这个线程...
是的，WPF 是一项出色的技术，它的好处远远超出了单纯的视觉效果......模板和绑定功能就是很好的例子。整个对象模型提供了更多的灵活性和更广泛的可能性。然而，这并不能使其成为未来 LOB 应用程序事实上的平台。
WPF 在将 GUI 与业务逻辑分离方面解决的“问题”并不是在 Windows 窗体中通过简单地从正确的体系结构和思维方式开始就可以轻松解决的问题。甚至 WPF 的对象路径绑定功能也可以通过一些非常简单的帮助器类在 Windows 窗体中重现。WPF 的数据模板功能非常好，但是在极少数情况下，当您完全不知道要在 Windows 窗体的任何给定部分上表示什么对象时，它们也不是您无法模拟的。屏幕。
Windows 窗体的领先之处在于成熟度。如果你不访问某个已经为你解决了 Windows 窗体问题的博客，你就不可能在 Google 上摇摆不定。另一方面，WPF 的可用学习资源相对较少，可用的自定义控件也较少，并且尚未解决许多初期问题。
在做出 WPF 与 Windows Forms 决定时，必须考虑开发环境的成熟度。Windows 窗体编辑器流畅、响应灵敏且直观。有关错误的反馈会立即到达，解决方案通常很明显，并且 Windows 窗体中的编译->调试->编辑周期非常快。
另一方面，WPF 应用程序的设计时支持相对较差，设计视图在第一次遇到错误时就很容易畏缩，通常需要在修复后构建项目，然后设计人员才愿意开始工作再次。考虑到在很多情况下它要么根本不起作用，要么产生完全不直观的结果，从工具箱中拖放组件也可能不受支持。尽管 WpfToolkit 做出了承诺，但仍然没有一个可用的 WPF DataGrid 可以产生任何合理的性能或设计时友好性。
调试 WPF 应用程序有点像 老的 ASP.NET 调试范例...打 F5 -> 等待 -> 启动 -> 错误 -> 停止 -> 修复 -> 命中 F5 -> 等待 -> 启动 -> 错误 -> 呻吟 -> 停止 -> 修复 -> 命中 F5....程序运行的所有 XAML 都被锁定，跟踪 XAML 特定问题通常很乏味。
简而言之，底线是 Windows 窗体开发工具将让您在 WPF 应用程序的一小部分时间内完成前端工作... 尤其 如果您正在创建主从网格或类似电子表格的界面，大多数 LOB 都有这些界面。使用 Windows 窗体，您可以从已经为您完成的 90% 的工作开始。
我是 WPF 架构的忠实粉丝。我只是希望设计时工具集不像是预阿尔法调试构建。
编辑：此答案是关于 .NET 3.5 + Visual Studio 2008 发布的，但是带有 Visual Studio 2010 的 .NET 4.0 附带了 WPF 数据网格。虽然新的WPF开发体验做了很多改进，但我这里的答案保持不变，我想补充以下建议：
如果你急于做 RAD 开发，使用Windows Forms。如果您希望生成一个架构良好、可维护、可扩展、资源友好、多用户业务线应用程序，请考虑 ASP.NET MVC + HTML 5 + jQuery...我使用这些技术的项目为我的客户更快地带来了更好的结果。MVC 提供与 WPF 相同的所有模板，并且 jQuery 支持动画和复杂的交互。更重要的是，ASP.NET MVC + jQuery 解决方案不需要您的最终用户拥有具有良好图形硬件的现代桌面。
我已经在客户的核心系统上使用 WPF 七个月了，我想与您分享一些关于学习和使用 WPF 作为业务线演示平台的经验的更多想法。
总的来说，我上面的评论仍然成立......对 WPF 的设计时支持尚未实现。如果您急于推出富客户端应用程序，请选择 Windows 窗体。时期。Microsoft 并不急于停止 GDI/Windows 窗体平台，因此您可以在未来一段时间内获得良好的支持。
WPF 并不容易掌握, ，但这不应该是您决定是否投入时间和精力学习 WPF 的地方。尽管 WPF 目前还不够成熟，但它是围绕一些有用的现代概念构建的。
例如，在 WPF 中，您对编写良好且具有健全验证逻辑的业务对象的投资是一项可靠的投资。与 Windows 窗体不同，WPF 的数据绑定具有允许界面控件对无效用户输入做出反应的功能 无需编写GUI代码 来检测这些错误。这是很有价值的。
WPF 中的样式和模板功能也被证明是有价值的。尽管人们普遍误解样式和模板的唯一用途是创建屏幕上的视觉效果，但事实是，这些功能显着简化了用户界面的编码，从而提供了丰富的反馈 - 例如根据情况禁用/启用自身的按钮底层业务逻辑层的状态，或根据光标下对象的状态智能查找文本的工具提示等。
这些都为“没什么花哨”的功能带来了极其有价值的功能 商业应用, ，仅仅是因为它们可以轻松地保持界面与底层数据的一致。
简而言之：
- 在Windows表单中，您设计了用户界面，然后编写代码来驱动该用户界面，该界面通常还包括用于驱动数据对象的代码。
- 在 WPF 中，您投资驱动数据对象的业务层，然后设计一个接口 听 到您的数据对象。
这是一个看似微妙的差异，但它对您重用代码的能力产生了巨大的影响......这就引出了一个问题：“Windows Forms 与 WPF 的问题实际上是一个投资决策吗？”
（这似乎已成为我最喜欢的话题。）
使用 WPF 是否有任何令人信服的理由
绝对地！WPF 绝对令人难以置信！这对于几乎任何项目来说都是一个重大好处，因为它具有 Windows 窗体所缺乏的许多特性和功能。
对于商业应用程序来说，最大的胜利将是：
- 出色的数据绑定和模板带来了最大的不同。一旦建立了合适的数据模型，只需点击几下即可创建数据模板并使用 表达混合 使用拖放功能准确配置对象的外观。与颜色或形状等事物的绑定是微不足道的。
- 屏幕布局非常灵活。WPF 中的所有内容不仅可以平滑地调整以适应容器大小和形状的变化，而且项目可以轻松放大和旋转，甚至延伸到其包含框架之外。
- 普通对象可以以您喜欢的任何方式呈现，可以轻松地在不同屏幕中具有不同的呈现方式，可以共享呈现方式，并且可以使其呈现方式适应数据值的变化。
- 如果您需要打印，渲染到打印机就很简单了。正确配置后，WPF 使 水晶报表 或者 SQL Server 报告服务 （SSRS）看起来像个孩子的玩具。
- 您的用户界面将看起来和感觉起来更加动态，包括一些不错的功能，例如当您将鼠标滑过它们时会产生动画的按钮。
对于实用程序和游戏来说，其他优势也尤为突出：
- 您可以轻松地将形状、线条和任意绘图添加到您的应用程序中，而无需使用外部编辑器。其中的每个组件都可以是数据绑定和动画的，或者由代码控制。在 Windows 窗体中，您通常只需导入位图并按原样使用它，除非您想要进行大量工作。
- 动画很酷！只要你不过分，用户就会留下深刻的印象。它们还可以帮助人们了解正在发生的事情并减少高亮显示的需要。例如，拖动对象时，您可以为目标设置动画，以显示放下它时会发生什么。
- 颜色、渐变填充、画笔、精美字体、任何对象的旋转、平铺画笔等。任何你想要的图形化的东西都可以满足你的要求。
- 令人难以置信的可定制性。我需要为一个应用程序绘制铁轨，这样我就可以在上面放置一列火车。几个小时后，我有了可以在屏幕上任何地方绘制的铁轨 贝塞尔曲线, ，他们会自动加入并切换。
最重要的是，您可以在 Windows 窗体中构建的任何大型 GUI 都可以在 WPF 中构建，只需三分之一（或更少）的工作量，并且看起来更好。
WPF 是否需要更多资源（特别是 RAM）
与 Windows 窗体相比，您确实付出了一定的代价，但这个代价很小。
- RAM 可以增加或减少，具体取决于您的实现。WPF 更有效地存储数据，因此单个对象更小，但 WPF 中的对象往往比 Windows 窗体中的对象多，因此这可以实现平衡，并且任何一个都可以领先。
- 与 Windows Forms 相比，CPU 会上升。根据我的经验，屏幕上 WPF 对象的实际更新所需的 CPU 大约是正常 Windows 窗体渲染的两倍。如果您的应用程序大部分时间都花在更新屏幕上，那么 WPF 可能不适合您。但在这种情况下，您可能也没有使用 Windows 窗体：大多数严肃的游戏都是直接写入的 直接X.
- WPF 的磁盘使用量会稍微少一些，因为它所需的代码比 Windows 窗体少得多。当然，数据的大小将相同。
关于 CPU 使用的另一项注意事项：由于其保留模式存储，动画和转换（运动、平移等）在 WPF 上实际上比在 Windows 窗体中更高效。物体最初到达那里的速度较慢。
维护费用
WPF 是一个 巨大的 在维护方面胜过 Windows 窗体。由于所有内容都是用以前 1/5 的代码完成的，因此需要维护的代码也减少了 1/5。另外，所有样板文件都消失了，因此您可以专注于实际工作的代码。
XAML 的好处
XAML 是WPF的核心。虽然 WPF 可以在没有 XAML 的情况下使用，但 XAML 使其非常易于使用。XAML 具有 HTML 轻松指定用户界面的能力，但它的内置标记更强大，您可以轻松定义自己的标记。（其实这样做很正常）。
XAML 的一些具体优点：
- 您的整个 UI 都在一个文本文件中定义，该文件对于用户和工具来说都易于阅读和操作
- MarkupExtensions 允许以清晰简单的方式指定 Bindings
- 类型转换器允许轻松指定复杂类型的属性。例如，您可以说 Brush="Green"，也可以指定具有三个停止点的径向渐变画笔。
- 您可以创建自己的元素
- 您可以轻松利用 WPF 强大的“附加属性”
其他见解
我多年来一直梦想有像 WPF 这样的东西。许多人已经实现了此功能的部分功能，但以这样的价格（0 美元）将所有功能集中到一个地方是令人惊奇的。
WPF 是对 Windows 窗体的巨大范式转变，需要一些时间来适应，但花在学习它上的时间会得到数倍的回报。
即使五年后，WPF 仍然存在一些缺陷，但一旦您体验过它，它的强大功能将让您彻底震惊。如果有人试图将您拖回 Windows 窗体，您只会又踢又叫。
尖端：- 一定要获得开发表达混合物的副本 - 偶尔手动编辑XAML-一开始看起来很奇怪时不要放弃
WPF 需要 Windows Vista 或 Windows XP SP2，这不是一项繁重的要求，但却是一项相关要求。如果您想在 Windows 2000 上运行（有些人仍然这样做），那么 WPF 将不适合您。
WPF 也是一项较新的技术，不如 Windows 窗体那么成熟，因此您可以选择 Windows 窗体作为风险较小的选项，特别是对于大型应用程序。
话虽如此，WPF 是未来。Visual Studio 2010正在WPF中重写，这可能是迄今为止最大的WPF应用程序，也将是对该技术的真正考验。
显然，旧版 Windows 窗体应用程序将是另一种正确选择的情况。
正如其他人所说，无论哪种方式都有优点和缺点。正如其他人所说，WPF 的优点包括：
- 能够制作非常丰富的用户界面 相对地 容易地。
- 更简单的动画和特效
- 固有的可扩展性（在 WPF 应用程序和 Windows 窗体应用程序上使用 Windows Vista 放大镜工具：请注意，在 WPF 应用程序中，所有矢量艺术都可以完美缩放）
- （意见提醒）我觉得在 WPF 中制作面向文档的系统“更容易”
然而，WPF 也有一些缺点，其中 Windows 窗体表现最好：
- WPF 的内置控件套件比 Windows 窗体的控件套件要有限得多。
- Windows 窗体的第三方控件空间提供了更多支持。（当然，这种情况正在改变，但想一想：Windows 窗体自 2001 年就已出现；WPF才几年。凭借时间的优势，Windows Forms 在社区中得到了更多的支持。）
- 大多数开发人员已经了解 Windows 窗体；WPF 提供了新的学习曲线
最后，请记住，如果您愿意这样做（或使用正确的第三方工具），您可以在任一工具中创建出色的、有吸引力的和引人入胜的 UI。归根结底，两者都不一定在所有情况下都更好。使用适合项目的东西。
WPF 的编程模型比 Windows 窗体更加开放和灵活，但与 ASP.NET MVC 一样，它在正确实现模型-视图-视图模型模式方面需要更多的纪律。
我的第一次 高球 使用 WPF 的应用程序最终彻底失败，因为它占用大量资源，导致我的最终用户的超低端笔记本电脑陷入瘫痪......这最终是因为我刚刚加入了 WPF + LINQ 到 SQL 并期待一个好的结果...这就是 WPF 与 Windows 窗体的显着不同之处......在 Windows 窗体中，您可以摆脱这种事情。WPF 比 Windows 窗体占用的资源要重得多，如果您不将应用程序设计得精益，那么您最终会变成一只 800 磅重的大猩猩。
不要回避 WPF...探索它。但请注意，Windows 窗体编码中可接受的错误不会在 WPF 中产生良好的结果。它们是根本不同的引擎，因此适用于根本不同的编码模式。
遗言：如果您确实继续使用 WPF，请充分熟悉用于列表和网格的数据虚拟化。简单的数据绑定 ListItem 或 GridCell 最终会成为 WPF 中庞大的逻辑 + 可视对象图，如果您不学习如何虚拟化，您的应用程序将无法在大型数据集上表现良好。
这两种技术都有其优点和缺点。在具有“经典”UI 的大型应用程序中，我会使用 Windows 窗体。在需要丰富的用户界面（皮肤、动画、更改用户界面）的应用程序中，我会选择 WPF。请查看文章 WPF 对比Windows 窗体 比较 WPF 和 Windows 窗体。
除了 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
我认为WPF值得学习。恕我直言，一旦您掌握了速度，表单的设计工作就会容易得多。我不会太担心“性感”的东西。其中大部分只是一种时尚。您可以在 WPF 中非常快速、轻松地制作“普通”Winforms 样式的应用程序。
在我看来，整个概念使设计变得更容易。
我不同意这里的一些答案。WPF 确实非常适合 业务范围 （LOB）应用程序。（青蛙设计的LOB客户端就是最好的例子）。除了使您的 UI 引人注目（这在业务应用程序中不是必需的）的所有可能性之外，WPF 还为您提供了更多功能。
数据绑定和模板功能仅优于 Windows 窗体。它还提供了一种更好的分离代码和表示的方法。我们已成功将 WPF 用于 2-3 名开发人员的团队中的 2 个 LOB 应用程序。
您将面临的最大问题可能是 WPF 的陡峭学习曲线（与 Windows 窗体相比），这会降低不习惯 WPF 的开发人员的开发速度。
如果界面设计对您很重要，请考虑 WPF，因为 WPF 可以提供更好的 UI 体验。但 Windows 窗体经过了多年的发展，因此它已被证明是有效的，并且您可以找到许多精通该平台的程序员。
另外，可移植性也可能是一个问题，WPF 仅适用于 Windows XP SP2 及更高版本。
此外，WPF 的学习曲线很陡，这意味着如果没有特定的 WPF 经验，交付高质量的产品并不容易。
嗯，一个答案是“当您必须支持 1.1 或 2.0 时”，因为 WPF 是 .NET 3.0 的一部分。WPF 存在已知的操作系统限制，并且存在一个明显的技能问题：如果您有一个了解 winforms 的开发团队，那么编写健壮的代码可能会更容易 和 winforms。但是，如果您正在编写大量 UI 代码，那么在某个时候可能值得开始学习 WPF。
WPF 还与 Silverlight 有很多共同点，因此它具有可转移的优势。
WPF具有许多优点，例如出色的数据绑定功能，关注点的分离，设计和逻辑的分离等...
作为开发人员，我喜欢使用XAML定义UI而不是与Windows Forms Designer绑定的能力，并且我知道我可以依靠另一位设计师来使我的应用看起来不错。
就我个人而言，我不在乎旧版本的Windows不支持，但是WPF的最大问题之一是Mono（目前/曾经）支持的是（目前/曾经）http://www.mono-project.com）因此 WPF 应用程序无法在 Mac OS 或 Linux 上运行。（尽管 Silverlight 应用程序会）。
如果您有时间和资源投资学习 WPF，那就去做吧！即使您要编写 Silverlight 应用程序来支持多个操作系统。
如果您需要桌面应用程序在多个操作系统上运行，请坚持使用 SWF。
有很多差异。我们喜爱 WPF 的原因是：
- 声明式编程风格。
- 动画和状态转换
- Expression Blend 是一个很棒的工具
- 良好的风格支持。
但是，我们坚持使用 Windows 窗体，因为：
- 开发人员在已经知道Windows表单时学习WPF所需的额外时间。
- WPF不会在Windows 2000或更低的情况下运行。
在决定使用哪一个时，最重要的考虑因素是考虑目标受众安装的 .NET Framework。我发现更多的人拥有较低的 .NET Framework 版本，仅支持 Windows 窗体，但这只是我个人的经验。
WPF 的优点是可以更轻松地使用自定义控件和动画创建美观的 GUI。WPF 还有助于进一步分离表示层和逻辑层。如果您有设计师，它可以让您将 95% 的工作交给非编码人员，并允许编码人员处理逻辑。缺点是 Expressions Blend 的软件成本较高，并且缺乏任何运行良好的 Visual Studio 代码分析工具，因为它们往往会陷入尝试呈现 XAML 的框架调用中。我确信还有其他人，但这是我们真正看到的唯一两个。
主要考虑因素是您是否希望要求客户必须安装 .NET 3.0 甚至更好的 .NET 3.5 SP1。你会得到一些负面反馈
WPF 使将表单设计工作移交给实际的设计师（而不是披着设计师外衣的开发人员）变得更加容易。如果这是您想要做的事情，WPF 就是您的答案。如果经典 Windows 风格的按钮没问题，那么 Windows 窗体可能是最佳选择。
（多个答案都声称如果界面设计“对您很重要”，您应该使用 WPF，但这非常模糊。界面设计始终“重要”。）
如果您有 MSDN 许可证，请查看 表达工具. 。它是专门为 WPF 设计的，直接导出到 Visual Studio，它可以帮助您轻松过渡。
如果您只关心支持 Windows 并且不介意学习它所需的时间，请选择 WPF。它快速、灵活、易于重新设计，并且拥有出色的工具来使用它。
另外一个好处是，Silverlight 基于 WPF，从其中一个开始，您就可以了解如何与另一个一起工作。如果事情继续基于网络，那么拥有可以轻松传输到浏览器（或 Windows Live Mesh）的先验知识（和现有代码库）可能有助于为您的软件带来额外的生命力。
如果您决定使用 WPF，考虑到上面答案中已经解释的优缺点，我强烈建议您阅读一下 比利·霍利斯 (Billy Hollis) 的 dnrTV 剧集
在 点网摇滚第 315 集, ，布莱恩·诺伊斯对此进行了广泛的讨论。
WPF 中的文本呈现存在一个已知问题。许多用户报告说，大量使用抗锯齿和像素混合会导致文本模糊。在某些情况下，这是一个重大问题，据我所知，微软在某种程度上已经承认了这一点。
在过去的 3 1/2 年里，我一直在进行 Windows 窗体开发（在两家公司）。这两个应用程序都被广泛使用，最终都出现了 GDI 问题。大型 Windows 窗体应用程序最终将耗尽 GDI 资源 - 导致最终用户必须重新启动。
Scott 正在抱怨 Expression Blend 作为一名开发人员，这对他来说毫无意义。我对 Expression Blend 的第一反应就是这样。然而，现在我认为它是一个非常宝贵的工具，但这实际上取决于您是什么类型的开发人员。
我是用户界面开发人员，必须执行以下操作 积分器 我最终发现 Expression Blend 对于以所见即所得的方式创建样式和控制模板非常有用。我几乎总是让 Expression Blend 和 Visual Studio 同时在同一个项目上运行。
我还认为在 Expression Blend 中尝试一下并看看 XAML 这是学习 WPF API 的绝佳方法......就像在 Windows 窗体中使用设计器并检查它生成的 C# 代码一样，这有助于学习如何使用您在那里设计的任何内容。
表达混合很有帮助。请尝试一下，尤其是当您正在处理应用程序的视觉效果时。
引用自 马克之前的帖子:
- 在 Windows 窗体中，您设计用户界面，然后编写代码来驱动该用户界面，该用户界面通常还包括驱动数据对象的代码。
- 在 WPF 中，您投资驱动数据对象的业务层，然后设计一个侦听数据对象的接口。
我认为这更多的是一种设计选择，而不是您是否使用 Windows 窗体或 WPF。然而，我可以理解某些技术可能更适合特定的方法。
仅当您没有 WPF 专业知识并且您不想投资它时:)
