Windows 窗体的大多数限制和技巧对大多数程序员来说都是常见的。但由于 .NET 3.0 也有 WPF 可用,即 Windows Presentation Foundation。据说您可以使用它使“性感应用程序”更容易,并且使用 .NET 3.5 SP1 可以很好地提高执行速度。
但另一方面,很多事情都与 WPF 不同。我不会说它更难,但你必须从头开始学习“一切”。
我的问题:当您必须创建一个新的 GUI 并且项目没有时间压力时,是否值得花费这些额外的时间?
在尝试在 WPF 上敲定一个业务线(LOB) 应用程序三个月后,我达到了考虑将我的项目转回 Windows 窗体的地步,并在研究其他人的意见时,遇到了这个线程......
是的,WPF 是一项出色的技术,它所带来的好处远远超出了视觉上的吸引力……模板和绑定功能就是很好的例子。整个对象模型提供了更大的灵活性和更广泛的可能性。然而,这并不能使它成为未来 LOB 应用程序的实际平台。
WPF 在将 GUI 与业务逻辑分离方面解决的“问题”并不是在 Windows 窗体中通过简单地从正确的架构和思维方式开始就无法轻易解决的问题。甚至 WPF 的对象路径绑定功能也可以通过一些非常简单的帮助类在 Windows 窗体中重现。WPF 的数据模板功能非常好,但在极少数情况下,当您完全不知道要在任何给定部分上表示哪些对象时,它们又不是您无法在 Windows 窗体中模拟的。屏幕。
Windows Forms 领先的地方在于成熟度。如果不访问某人为您解决了 Windows 窗体问题的博客,您就无法在 Google 上挥动一只死猫。另一方面,WPF 的可用学习资源相对较少,可用的自定义控件较少,而且还没有解决很多初期问题。
在做出 WPF 与 Windows 窗体决策的高峰期,必须是开发环境的成熟度。Windows 窗体编辑器流畅、响应迅速且直观。有关错误的反馈会立即发送给您,解决方案通常很明显,并且 Windows 窗体中的编译->调试->编辑周期非常快。
另一方面,WPF 应用程序具有相对可怜的设计时支持,设计视图在第一次遇到错误时已经准备好退出,通常需要在修复后构建项目,然后设计师才愿意参与再次。考虑到在很多情况下它要么根本不起作用,要么产生完全不直观的结果,因此也可能不支持从工具箱中拖放组件。尽管有 WpfToolkit 的承诺,但仍然没有用于 WPF 的可用 DataGrid 产生任何类型的合理性能或设计时间友好性。
调试 WPF 应用程序有点像旧的ASP.NET 调试范例...命中F5-> 等待 -> 启动 -> 错误 -> 停止 -> 修复 -> 命中F5-> 等待 -> 启动 -> 错误 -> 呻吟 -> stop -> fix -> hit F5.... 程序运行的所有 XAML 都被锁定,跟踪 XAML 特定问题通常很乏味。
简而言之,Windows 窗体的开发工具将让您在 WPF 应用程序的一小部分时间内完成前端工作……尤其是在您创建主从网格或电子表格时像大多数 LOB 都有的接口。使用 Windows 窗体,您可以从已经为您完成的 90% 的工作开始。
我是 WPF 架构的忠实粉丝。我只是希望设计时工具集不像预 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 解决方案不要求您的最终用户拥有具有良好图形硬件的现代桌面。
我已经使用 WPF 七个月了,现在它已成为我的客户的核心系统,我想与您分享一些关于学习和使用 WPF 作为业务线演示平台的经验的更多想法。
总的来说,我上面的评论仍然成立…… WPF 的设计时支持还没有出现。如果您急于推出富客户端应用程序,请使用 Windows 窗体。时期。Microsoft 并不急于停止 GDI / Windows Forms 平台,因此您可以在未来一段时间内获得良好的支持。
WPF 并不容易掌握,但这不应该是您决定是否投入时间和精力学习 WPF 的地方。尽管 WPF 目前还不够成熟,但它是围绕一些有用的现代概念构建的。
例如,在 WPF 中,您对编写良好且具有健全验证逻辑的业务对象的投资是一项可靠的投资。与 Windows 窗体不同,WPF 的数据绑定充满了允许界面控件对无效的用户输入做出反应而无需编写 GUI 代码来检测这些错误的功能。这是有价值的。
WPF 中的样式和模板功能也被证明是有价值的。尽管人们普遍认为样式和模板的唯一用途是创建屏幕上的视觉效果,但事实是这些功能显着简化了提供丰富反馈的用户界面的编码 - 例如禁用/启用自身的按钮底层业务逻辑层的状态,或根据光标下对象的状态智能查找其文本的工具提示等。
所有这些都为“没什么花哨的”业务应用程序添加了非常有价值的功能,仅仅是因为它们使界面与底层数据保持一致变得容易。
简而言之:
这似乎是一个微妙的差异,但它对您重用代码的能力产生了巨大的影响......这就引出了一个问题:“Windows 窗体与 WPF 的问题实际上是一个投资决定吗?”
(这似乎已成为我最喜欢的线程。)
是否有任何令人信服的理由使用 WPF
绝对地!WPF 绝对令人难以置信!对于几乎任何项目来说,这将是一个主要的好处,因为它具有 Windows 窗体所缺乏的许多特性和能力。
对于业务应用程序,最大的胜利将是:
对于实用程序和游戏而言,其他优势尤为突出:
最重要的是,您可以在 Windows 窗体中构建的任何大型 GUI 都可以在 WPF 中构建,只需三分之一(或更少)的工作量,并且看起来更好。
WPF 是否需要更多资源(尤其是 RAM)
与 Windows 窗体相比,您确实付出了一些代价,但代价很小。
关于 CPU 使用的另一个注意事项:动画和变换(运动、平移等)实际上在 WPF 上比在 Windows 窗体中更有效,因为它具有保留模式存储。最初获取物体的速度较慢。
维护费用
在维护方面, WPF 是对 Windows 窗体的巨大胜利。由于一切都是用以前的 1/5 代码完成的,因此需要维护的代码也只有 1/5。此外,所有样板文件都消失了,因此您可以专注于实际完成工作的代码。
XAML 的好处
XAML是 WPF 的核心。尽管 WPF 可以在没有 XAML 的情况下使用,但 XAML 使其非常易于使用。XAML 具有 HTML 轻松指定用户界面的能力,但其内置标签功能更强大,您可以轻松定义自己的标签。(其实这样做很正常)。
XAML 的一些特定优势:
其他见解
多年来,我一直梦想着像 WPF 这样的东西。许多人已经实现了这个功能的一部分,但是以这样的价格(0 美元)将它们全部集中在一个地方是惊人的。
WPF 是从 Windows 窗体发生的巨大范式转变,需要一些时间来适应,但花在学习上的时间会带来很多倍的回报。
WPF 即使在五年后仍然有一些缺点,但一旦你体验它的力量,它的力量会让你大吃一惊。如果有人试图将您拖回 Windows 窗体,您只会大喊大叫。
提示: - 一定要获得一份用于开发的 Expression Blend - 偶尔手动编辑 XAML - 当它一开始看起来很奇怪时不要放弃
WPF 使您能够做一些令人惊奇的事情,我喜欢它……但是,每当开发人员问我是否认为他们应该转向新技术时,我总是觉得有义务证明我的建议。
您的开发人员是否愿意(最好是 EAGER)花时间学习有效地使用 WPF?我从来没有想过要对 MFC、Windows 窗体甚至非托管 DirectX 这么说,但您可能不希望团队在正常开发过程中尝试“拿起”WPF。运输产品的周期!
是否至少有一两个开发人员具有一定的设计敏感性,并且具有最终设计权限的个人是否对开发问题有很好的理解,因此您可以利用 WPF 功能来创建实际上更好的东西,而不仅仅是更“多彩” ,以免费动画为特色?
您的目标客户群中是否有一部分运行在可能不支持您计划的功能的集成图形芯片组上——或者他们是否仍在运行 Windows 2000,这将完全排除他们作为客户的身份?有些人还会问您的客户是否真的关心增强的视觉效果,但是在经历了 90 年代初期公司内部“我们的业务客户不关心颜色和图片”的辩论后,我知道您的竞争对手精心设计的解决方案会让他们关心,真正的问题是条件是否合适,使您能够提供让他们现在关心的东西。
项目是否涉及底层开发,至少对于表示层,以避免尝试挂钩到不兼容的遗留脚手架的额外复杂性(与 Win Forms 的互操作不是无缝的)?
您的经理能否接受(或分散注意力)在四到六个月内开发人员生产力的显着下降?
最后一个问题是由于我喜欢将 WPF 视为“FizzBin”性质,有十种不同的方式来实现任何任务,没有明显的理由偏爱一种方法,而且很少有指导可以帮助您制作选择。您所做的任何选择的缺点不仅会在项目的后期变得很明显,而且您几乎可以保证项目中的每个开发人员都采用不同的方法,从而导致严重的维护问题。最令人沮丧的是,当您尝试学习该框架时,经常会遇到不一致性。
您可以在我的博客上的条目中找到更深入的 WPF 相关信息:
WPF 需要 Windows Vista 或 Windows XP SP2,这不是一项繁重的要求,但它是一个相关的要求。如果您想在 Windows 2000 上运行(有些人仍然这样做),那么 WPF 将不适合您。
WPF 也是一种较新的技术,不如 Windows 窗体经过验证,因此您可以选择 Windows 窗体作为风险较小的选项,尤其是对于较大的应用程序。
话虽如此,是的,WPF 是未来。Visual Studio 2010 正在用 WPF 重写,这可能是迄今为止最大的 WPF 应用程序,它也将是对该技术的真正测试。
显然,旧的 Windows 窗体应用程序将是另一种情况,它是正确的选择。
正如其他人所说,无论你走到这里,都有优点和缺点。正如其他人所说,WPF 的优点包括:
但是,WPF 也有一些缺点,Windows 窗体在其中占据优势:
最后,请记住,如果您完成工作(或使用正确的第三方工具),您可以在任一工具中创建出色、有吸引力和引人入胜的 UI。归根结底,在所有情况下,两者都不一定更好。使用适合项目的东西。
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 有一个非常陡峭的学习曲线,我建议您首先获得显而易见的书籍(Adam Nathan、 Sells/Griffiths和 Chris Anderson)和博客(Josh Smith等)。只需为此做好准备,并确保您的项目允许您有时间学习 WPF。
除了学习技术之外,还要花一些时间学习用于构建 WPF 应用程序的模式。模型视图视图模型(MVVM) 似乎是获得了广泛认可的模型。
就个人而言,我认为 WPF 是值得的,但要预先警告。另请注意,您有效地将用户限制为 Windows XP SP2+ 和 Windows Vista。我们已经做出了决定,但您可能有一些不同的要求。
这两种技术都有其优点和缺点。在具有“经典” 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 风格的应用程序。
整个概念有助于更轻松地设计 IMO。
我不同意这里的一些答案。WPF 非常适合业务线(LOB) 应用程序。(青蛙设计 LOB 客户端就是最好的例子)。除了让您的 UI 变得引人注目(这在业务应用程序中不是必需的)的所有可能性之外,WPF 还为您提供了更多。
数据绑定和模板功能只是优于 Windows 窗体。它还提供了一种更好的方法来分离代码和表示。我们已经在不超过 2-3 名开发人员的团队中成功地将 WPF 用于 2 个 LOB 应用程序。
您将面临的最大问题可能是 WPF 的陡峭学习曲线(与 Windows 窗体相比)这将降低不习惯 WPF 的开发人员的开发速度。
我们目前正在从 Windows 窗体用 WPF 重写我们的应用程序。是的,有一个陡峭的学习曲线,你必须“重新学习”一些东西,但这是非常值得的。结合 WCF,我们发现我们编写的代码比以往任何时候都更少、更快、更健壮。
坚持一段时间,阅读Adam Nathan 的书,并查看不断增长的第三方控件库,例如来自Telerik和ComponentOne的那些。在我看来,一个负面因素是设计工具Expression Blend使用起来非常尴尬。最新版本仍处于测试阶段,但对于我们这些使用 Visual Studio 多年的人来说,感觉不太对劲。是的,它主要面向设计师,但有些事情在 Visual Studio 中是做不到的。
如果界面设计对您很重要,请考虑 WPF,因为 WPF 可以提供更好的 UI 体验。但是 Windows Forms 拥有多年的演变,因此它被证明是有效的,并且您可以找到许多精通该平台的程序员。
可移植性也可能是一个问题,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 窗体设计器,我很高兴知道我可以依靠另一个设计器来使我的应用程序看起来不错。
就我个人而言,我不在乎不支持旧版本的 Windows,但 WPF 的一个大问题是 Mono ( http://www.mono-project.com ) 不支持 (当前/曾经) 所以 WPF应用程序不会在 Mac OS 或 Linux 上运行。(尽管 Silverlight 应用程序会)。
如果您有时间和资源投入学习 WPF,那就去做吧!即使您要编写 Silverlight 应用程序来支持多个操作系统。
如果您需要桌面应用程序在多个操作系统上运行,请使用 SWF。
有很多不同之处。我们喜欢 WPF 是因为:
但是,我们坚持使用 Windows 窗体,因为:
在决定使用哪一个时,最大的考虑是考虑您的目标受众安装了什么 .NET Framework。我发现更多人拥有仅支持 Windows 窗体的较低 .NET Framework 版本,但这只是我的个人经验。
WPF 的优点是使用自定义控件和动画创建漂亮的 GUI 更加容易。WPF 还有助于进一步分离表示层和逻辑层。如果您有设计师,它可以让您将 95% 的工作交给非编码人员,并允许编码人员从事逻辑工作。缺点是 Expressions Blend 的软件成本,以及缺乏任何运行良好的 Visual Studio 代码分析工具,因为它们往往会在尝试呈现 XAML 时陷入框架调用。我相信还有其他人,但这是我们真正看到的仅有的两个。
主要考虑因素是您是否希望要求您的客户必须安装 .NET 3.0 甚至更好的 .NET 3.5 SP1。你会得到一些负面的反馈
WPF 使将表单设计工作交给实际设计师而不是设计师服装的开发人员变得更加容易。如果这是您想做的事情,WPF 就是您的答案。如果经典的 Windows 样式按钮很好,那么 Windows 窗体可能是要走的路。
(多个答案声称如果界面设计“对您很重要”,您应该使用 WPF,但这很模糊。界面设计始终是“重要的”。)
如果您有 MSDN 许可证,请查看Expression tools。它专为 WPF 设计,直接导出到 Visual Studio,它可能有助于简化您的过渡。
如果您只关心支持 Windows 并且不介意学习它所需的时间,请使用 WPF。它快速、灵活、易于重新设计,并且有很好的工具来使用它。
作为附带的好处,Silverlight 基于 WPF,从其中一个开始,您可以了解如何与另一个一起工作。如果事情继续以 Web 为基础,拥有可以轻松传输到浏览器(或 Windows Live Mesh)的先验知识(和现有代码库)可能有助于为您的软件提供额外的生命。
如果您决定使用 WPF,考虑到上述答案中已经解释的利弊,我强烈建议您与比利霍利斯一起阅读这个 dnrTV 剧集
在DotNetRocks 第 315 集中,Brian Noyes 广泛讨论了这一点。
在过去的 3 1/2 年里,我一直在进行 Windows 窗体开发(在两家公司)。这两个应用程序都被广泛使用并最终遇到了 GDI 问题。大型 Windows 窗体应用程序最终将耗尽 GDI 资源 - 导致最终用户必须重新启动。
WPF 中的文本呈现存在一个已知问题。许多用户报告说,大量使用抗锯齿和像素混合会导致文本模糊。在某些情况下,这是一个大问题,据我所知,微软在某种程度上已经承认了这一点。
Scott 抱怨 Expression Blend以及作为一名开发人员对他来说没有意义。我对 Expression Blend 的第一反应就是这样。然而,现在我认为它是一个非常宝贵的工具,但这真的取决于你是什么类型的开发人员。
我是一名用户界面开发人员,必须扮演集成者角色,最终我发现 Expression Blend 对于以所见即所得的方式创建样式和控制模板非常有用。我几乎总是同时在同一个项目上运行 Expression Blend 和 Visual Studio。
我还认为,在 Expression Blend 中玩耍并查看吐出的XAML是学习 WPF API 的绝佳方式......就像在 Windows 窗体中使用设计器并检查它吐出的 C# 代码很有帮助学习如何使用你在那里设计的任何东西。
Expression Blend 很有帮助。试一试,特别是如果您正在处理应用程序的视觉效果。
- 在 Windows 窗体中,您设计用户界面,然后编写代码来驱动该用户界面,这通常还包括驱动数据对象的代码。
- 在 WPF 中,您投资于驱动数据对象的业务层,然后设计一个侦听数据对象的接口。
我认为这更多是一种设计选择,而不是您使用的是 Windows 窗体还是 WPF。但是,我可以理解某些技术可能更适合特定方法。
WPF 通过 XAML 对声明性 UI 的支持、丰富的控件模板和样式以及Expression Blend等工具,使得设计人员可以更好地与开发人员在同一个项目上合作。此外,它为开发人员提供了附加依赖属性和极其强大的数据绑定的灵活性。此外,Silverlight 支持 XAML 的子集和与 WPF 相同的控件类,因此您的应用程序可以轻松移植为RIA。
任何一天我都会选择 WPF 而不是 Windows 窗体。即使目标机器只有.NET 2.0,如果用户可以安装其他程序,新的 .NET Framework Client 配置文件也可以很容易地部署 WPF 应用程序。
我可能决定坚持使用 Windows 窗体的唯一原因是该产品是否将部署在锁定且只有 .NET 2.0 或 .NET 1.1 的机器上。
仅当您没有 WPF 专业知识并且不想投资时:)
对于转换项目(从Visual Basic 6.0开始),很难让团队切换到 WPF。除了学习曲线之外,人们已经习惯了旧界面。Windows 窗体虽然已被淘汰,但仍将存在很长时间。
我会使用 Winforms 来快速验证概念,因为虽然它对于实际应用程序来说很糟糕,但它对于“Visual Basic 6.0”——风格的快速原型设计来说非常好。
所以,这里有一个例子:
如果我需要跟踪流程的多个步骤(例如下载某些内容、计算/转换、创建智能输出)并使所有内容可重现,我通常会制作一个带有 ListBox 和几个按钮的快速表单。
因为我是一个真正的开发人员,所以逻辑已经在视图之外的类中,所以这是一个很好的起点。
使用 WPF 为您提供了在很大程度上自定义应用程序的方法。你可以非常快速地编码,即在几秒钟内创建一个像文本框一样的自定义控件,并自定义内容样式等各种属性,而最好的部分是UI美感,即动画,触发器等,图形。但它需要良好的硬件规格和一些仅在 Windows Vista 和 Windows 7 中可用的特殊功能。
Windows 窗体没有这些真正重要的丰富功能,否则我们可以使用它创建任何类型的应用程序,我们可以在 WPF 中使用它。
Windows Forms 和 WPF 完全是不同的物种,这完全取决于项目要求,即客户或用户想要什么。