在创build新的GUI时,WPF是Windows Forms的首选吗?

大多数程序员都会使用Windows窗体的大多数限制和技巧。 但是从.NET 3.0开始,还有WPF可用,即Windows Presentation Foundation。 据说你可以使“性感应用程序”更容易,.NET 3.5 SP1在执行时有很好的速度提升。

但另一方面,许多事情与WPF有所不同。 我不会说这是更难的,但你必须从头开始学习“一切”。

我的问题:当你需要创build一个新的graphics用户界面并且没有时间压力的时候,是否值得花费额外的时间?

WPF使您能够做出一些令人惊叹的事情,而且我喜欢它……但是每当开发者问我是否应该转向新技术时,我总是觉得有必要限制我的build议。

您的开发人员是否愿意(最好是EAGER)花费时间学习如何有效地使用WPF? 我从来没有想过要对MFC,Windows Forms,甚至是非托pipeDirectX这么说,但是你可能不希望一个团队试图在正常的开发过程中“拾取”WPF。 运输产品的周期!

至less有一两个开发人员有一些devise敏感性,最终devise权限的人对开发问题有一个正确的理解,所以您可以利用WPFfunction来创build实际上更好的东西,而不是更“多彩” ,以无偿animation为特色?

您的目标客户群是否有一定百分比运行在集成显卡芯片组上,这些芯片组可能不支持您正在计划的function – 或者他们仍在运行Windows 2000,这将消除它们作为客户? 有些人也会问你的客户是否真的关心增强的视觉效果,但是在90年代早期,经历过内部公司“我们的商业客户不关心色彩和图片”的辩论,我知道你的竞争对手的devise良好的解决scheme会让他们在乎,真正的问题是条件是否正确,使你能够提供一些能够使他们在乎的东西。

该项目是否涉及开发基础设施,至less在表示层,以避免额外的复杂性试图钩入不兼容的遗留脚手架(Interop与Win Forms不是无缝的)?

您的经理能否接受(或注意到)开发人员生产力显着下降四到六个月?

这最后一个问题是由于我喜欢认为WPF的“FizzBin”本质,有十种不同的方式来执行任何任务,并没有明显的理由更喜欢一种方法到另一个,一点的指导可以帮助你做一个select。 不仅如此,项目中任何select的缺点都会变得清晰,但实质上保证让项目中的每个开发人员都采用不同的方法,从而导致严重的维护头痛。 当你试图学习框架的时候,最令人沮丧的是不断出现的不一致。

您可以在我的博客上find更深入的WPF相关信息:

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

经过三个月的努力,在WPF上敲定了业务线 (LOB)应用程序之后,我达到了为我的项目考虑回到Windows Forms的angular度,并在研究其他人的意见时,碰到了这个线程。

是的,WPF是一个非常出色的技术,它的优点远远超出了眼光,模板和绑定function就是很好的例子。 整个对象模型提供更多的灵活性和更广泛的可能性 但是,这并不能成为未来LOB应用程序的事实平台。

WPF在将GUI与业务逻辑分离方面所解决的“问题”,不是简单地从正确的架构和思维开始就不能在Windows Forms中解决的问题。 即使是WPF的对象path绑定function,也可以使用一些非常简单的帮助程序类在Windows窗体中进行复制。 WPF的数据模板function非常好,但是在这些罕见的情况下,当你绝对不知道你将在任何给定的部分屏幕。

Windows Forms比赛在成熟的方面。 你不能在谷歌上摇动一只死猫,而不会碰到某人为你解决了Windows Forms问题的博客。 另一方面,WPF可用的学习资源相对较less,可用的定制控制较less,并没有解决许多问题。

在WPF和Windows Forms决策的高峰期,这个决定已经成为开发环境的成熟。 Windows窗体编辑器是光滑的,响应和直观的。 有关错误的反馈会立即得到,解决scheme通常很明显,Windows窗体中的编译 – >debugging – >编辑周期非常快。

另一方面,WPF应用程序具有相对可怜的devise时间支持,而devise视图全都准备好了,在第一次遇到错误时就已经准备好了,通常需要在修复之后在devise师愿意踢之前再次。 从工具箱中拖放组件可能不被支持,因为在很大范围内它根本无法工作,或者产生完全不直观的结果。 尽pipeWpfToolkit的承诺,仍然没有一个可用的WPF的DataGrid,产生任何forms的合理的性能或devise时友好。

debuggingWPF应用程序有点像旧的 ASP.NETdebugging范例…打F5 – >等待 – >启动 – >错误 – >停止 – >修复 – >打F5 – >等待 – >启动 – >错误 – >呻吟- >停止 – >修复 – >点击F5 ….你的程序运行的所有XAML都被locking了,跟踪XAML的具体问题往往是单调乏味的。

最简单的说,Windows Forms的开发工具将让您在WPF应用程序的一小部分时间内敲出前端… 特别是如果您正在创build主 – 细节网格或电子表格像大多数LOB所具有的接口一样。 使用Windows Forms,您已经为您完成了90%的工作。

我是WPF架构的粉丝。 我只是希望devise时工具集不像是一个前alpha版的debugging版本。


编辑:这个答案是关于.NET 3.5 + Visual Studio 2008发布的,但.NET 4.0与Visual Studio 2010一起提供了一个WPF数据网格。 虽然WPF的新开发经验已经有了很多改进,但我的答案仍然没有改变,我想补充以下build议:

如果您急于进行RAD开发,请使用Windows Forms。 如果您希望生成一个架构良好,可维护,可伸缩,资源丰富的多用户业务线应用程序,请考虑ASP.NET MVC + HTML 5 + jQuery …使用这些技术的项目带来了更好的结果,更快,为我的客户。 MVC提供了与WPF相同的模板,jQuery支持animation和复杂的交互。 更重要的是,一个ASP.NET MVC + jQuery解决scheme并不要求你的最终用户拥有体面的graphics硬件的现代桌面。

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

总的来说,我上面提出的评论仍然持有… WPF的devise时支持尚未到此为止。 如果您急于想让胖客户端应用程序走出门外,可以使用Windows Forms。 期。 微软并不急于停止GDI / Windows Forms平台,所以你可以指望在未来的公平时间里得到很好的支持。

WPF并不容易掌握 ,但这不应该成为你决定是否花时间和精力学习WPF的地方。 尽pipeWPF目前缺乏成熟度,但它是围绕一些有用的现代概念而构build的。

例如,在WPF中,您对具有良好validation逻辑的写作良好的业务对象的投资是一个坚实的投资。 与Windows Forms不同的是,WPF的数据绑定充满了各种function,允许界面控件对无效的用户input做出反应, 而无需编写GUI代码来检测这些错误。 这是有价值的。

WPF中的样式和模板function也被certificate是有价值的。 尽pipe常见的误解是,造型和模板的唯一用途是创build屏幕上的视觉效果,但事实是,这些function显着简化了用户界面的编码,从而提供丰富的反馈信息 – 如基于基础业务逻辑层的状态,或基于光标下的对象的状态智能地查找其文本的工具提示等等。

这些都为“没有什么特别的” 业务应用程序添加了令人难以置信的有价值的function,仅仅因为它们使界面与底层数据保持一致变得容易。

简而言之:

  • 在Windows窗体中,您可以devise用户界面,然后编写代码来驱动该用户界面,该界面通常还包含驱动数据对象的代码。
  • 在WPF中,您投资驱动数据对象的业务层,然后devise一个接口来监听数据对象。

这是一个看似微妙的差异,但是它重用了代码的能力也有很大的不同……这引出了一个问题:“Windows Forms和WPF的问题实际上是一个投资决定吗?

(这似乎已经成为我最喜欢的线程。)

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

绝对! WPF绝对不可思议! 对于几乎所有的项目来说,这将是一个主要的好处,因为它具有许多Windows窗体缺乏的function和能力。

对于商业应用来说,最大的胜利将是:

  • 奇妙的数据绑定和模板化是最大的区别。 一旦体面的数据模型就位,只需要点击几下就可以创build一个数据模板,并使用Expression Blend通过拖放function精确configuration对象的外观。 绑定到像颜色或形状的东西是微不足道的。
  • 屏幕布局非常灵活。 WPF中的所有东西不仅可以根据容器大小和形状的变化顺利调整,而且可以平滑地放大和旋转,甚至可以扩展到包含框架之外。
  • 普通的对象可以以任何你喜欢的方式呈现,可以在不同的屏幕上轻松地进行不同的演示,可以共享演示,并且可以使它们的performance适应数据值的变化。
  • 如果你需要打印,渲染到打印机是微不足道的。 正确configuration,WPF使Crystal Reports或SQL Server Reporting Services (SSRS)看起来像一个孩子的玩具。
  • 您的用户界面看起来更加dynamic,包括很好的function,例如在您将鼠标移到其上方时带有animation的button。

对于公用事业和游戏来说,其他的优势来到了最前沿:

  • 您可以轻松地将形状,线条和任意graphics添加到您的应用程序,而无需使用外部编辑器。 这些的每个组件都可以是数据绑定和animation的,或者是由代码控制的。 在Windows窗体中,你只需要导入一个位图并按原样使用,除非你想去做很多工作。
  • animation很酷! 用户会非常感动,只要你不过分。 他们还可以帮助人们看到正在发生的事情,并减less对高峰的需求。 例如,拖动对象时,您可以为目标设置animation,以显示如果放下该对象将会发生的情况。
  • 颜色,渐变填充,画笔,花哨的字体,任何对象的旋转,瓷砖画笔等等任何你想要的graphics是你的问。
  • 令人难以置信的可定制。 我需要为一个应用程序绘制铁轨,所以我可以放下火车。 几个小时后,我可以用Bézier曲线在屏幕上的任何位置绘制铁轨,然后自动join并切换。

底线是,任何可以在Windows窗体中创build的大尺寸GUI都可以在WPF中以三分之一(或更less)的方式构build,并且看起来更好。

WPF是否需要更多资源(特别是RAM)

与Windows Forms相比,您付出的代价是小的。

  • 内存可以上升或下降取决于你的实施。 WPF更有效地存储它的数据,所以单个对象更小,但WPF中的对象往往比Windows窗体中的对象多,所以这个平衡了,任何一个都可以提前。
  • 与Windows Forms相比,CPU将会上升。 根据我的经验,屏幕上WPF对象的实际更新大约是正常Windows窗体渲染的两倍。 如果您的应用程序花费大部分时间更新屏幕,WPF可能不适合您。 但是在这种情况下,您可能不会使用Windows Forms:大多数严肃的游戏都是直接写入DirectX的 。
  • 对于WPF来说,磁盘使用量会稍微less一些,因为它比Windows Forms要less得多的代码。 当然,数据的大小是一样的。

关于CPU使用的另一个注意事项:animation和变换(运动,翻译等)在WPF上比在Windows窗体中效率更高,因为它保留了模式存储。 这是最初得到的对象在那里是慢的。

维护开销

当涉及到维护时,WPF对Windows窗体是一个巨大的胜利。 因为所有的代码都是以前的1/5,所以有1/5的代码要维护。 再加上所有的样板文件都没有了,所以你可以专注于实际工作的代码。

XAML的好处

XAML是WPF的核心。 虽然WPF可以在没有XAML的情况下使用,但XAML使其非常易于使用。 XAML具有HTML轻松指定用户界面的能力,但其内置的标签function更强大,您可以轻松定义自己的标签。 (事实上​​,这样做是正常的)。

XAML的一些具体优势:

  • 您的整个用户界面都定义在一个易于阅读和操作的文本文件中,无论是用户还是工具
  • MarkupExtensions允许以明确和简单的方式指定绑定
  • types转换器允许指定复杂types的属性。 例如,您可以说Brush =“Green”,或者您可以指定一个带三个停止的径向渐变画笔。
  • 你可以创build自己的元素
  • 您可以轻松利用WPF强大的“附加属性”

其他见解

我梦想了WPF多年。 许多人已经实现了这个function的一部分,但是把它全部放在一个地方,价格($ 0)是惊人的。

WPF是Windows Forms的一个巨大的范式转换,需要一些习惯,但花费在学习上的时间会让自己回到很多倍。

WPF甚至五年后仍然有几个疣,但是一旦你体验到它的威力,它将完全把你吹走。 如果有人试图把你拖回到Windows窗体,你只会去踢和尖叫。

提示: – 获取Expression Blend的副本以供开发 – 偶尔手动编辑XAML – 不要放弃当初看起来很奇怪

WPF要求Windows Vista或Windows XP SP2,这不是一个繁重的要求,但它是一个相关的。 如果你想在Windows 2000上运行(有些人还是这么做的话),那么WPF将无法为你工作。

WPF也是一种较新的技术,并不像Windows窗体那样经过validation,因此您可以selectWindows窗体作为风险较小的选项,特别是对于较大的应用程序。

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

显然,遗留Windows窗体应用程序将是另一种情况,它是正确的select。

正如其他人所说,无论你走到哪里,都有优点和缺点。 正如其他人所说,WPF的优势包括:

  • 能够相对容易地制作非常丰富的用户界面。
  • 更简单的animation和特效
  • 固有的可伸缩性(在WPF应用程序和Windows窗体应用程序上使用Windows Vista放大镜工具:请注意,在WPF应用程序中,所有的vector图都精美地缩放)
  • (意见提醒)我觉得在WPF中执行面向文档的系统是“更容易”的

不过,WPF有一些缺点,Windows窗体出现在上面:

  • WPF的内置控件套件远比Windows窗体更有限。
  • Windows Forms的第三方控制空间有更大的支持。 (当然这正在发生变化,但想一想:Windows Forms自2001年以来就已经存在了,而WPF只有短短的几年时间,Windows Forms在这个社区中得到了更多的支持。
  • 大多数开发者已经知道Windows窗体; WPF提供了一个新的学习曲线

最后,请记住,如果您从事这项工作(或者使用正确的第三方工具),那么您可以在任一工具中创build出色的,吸引人的和吸引人的用户界面。 在一天结束的时候,在任何情况下都不一定更好。 使用什么感觉正确的项目。

WPF的编程模型比Windows Forms更加开放和灵活,但是像ASP.NET MVC一样,在正确实现Model-View-ViewModel模式方面需要更多的训练。

我的第一个使用WPF的LOB应用程序最终成为一个完全失败的应用程序,因为这是一个资源浪费,使我的terminal用户的低端笔记本电脑停滞不前…这最终是因为我只是用WPF + LINQ to SQL,并期待一个好的结果…这是WPF在Windows Forms中如此强烈的分歧…在Windows窗体中,你可以逃避这种事情。 WPF的资源比Windows窗体要重得多,如果你不把应用程序devise成精简的,那么你最终会得到一个800磅重的大猩猩。

不要回避WPF …探索它。 但是请注意,Windows Form编码的可接受的错误在WPF中不会产生好的结果。 它们是根本不同的引擎,它们本身就具有根本不同的编码模式。

最后一句话:如果您继续使用WPF,那么请熟悉数据虚拟化,以便与列表和网格一起使用。 什么是简单的数据绑定ListItem或GridCell最终成为WPF中的一个强大的逻辑+可视化对象图,如果您不学习如何虚​​拟化,那么您的应用程序在大型数据集上将无法正常运行。

WPF的学习曲线非常陡峭,我build议你先拿到明显的书( Adam Nathan , Sells / Griffiths和Chris Anderson )和博客( Josh Smith等)。 只需做好准备,并确保您的项目允许您有时间学习WPF。

除了学习技术之外,花一些时间学习用于构buildWPF应用程序的模式。 模型视图ViewModel (MVVM)似乎已经获得了很大的认可。

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

这两种技术都有其优点和缺点。 在具有“经典”UI的大型应用程序中,我会使用Windows窗体。 在需要丰富的用户界面(皮肤,animation,更改用户界面)的应用程序中,我会selectWPF。 请检查文章WPF与Windows窗体比较WPF和Windows窗体。

除了UIdevise的灵活性外,WPF还有一些技术优势:

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

2)WPF利用GPU。 WPF将一些UI处理function卸载到GPU的能力非常出色。 我只希望这个方面随着时间的推移而变得更好。 作为一名前OpenGL编程爱好者,我可以欣赏来自GPU的强大function。 我的意思是,我的$ 100显卡拥有112个内核,每个运行频率为1.5 GHz(这不是任何方式的顶端)。 这种并行处理能力可以让任何四核CPU感到羞耻。

不过,WPF还是很新的。 它不会在Windows 2000上运行。实际上,WPF应用程序在全新重新启动后可能启动缓慢。 我在我的博客上讨论所有这些: http : //blog.bucketsoft.com/2009/05/wpf-is-like-fat-super-hero.html

我认为值得学习WPF。 一旦你达到了速度,在你的表单上devise工作更容易恕我直言。 我不会担心“性感”的东西。 大部分这只是一个时尚。 您可以在WPF中快速,轻松地创build“普通”Winforms风格的应用程序。

整个概念有助于简化IMOdevise。

我不同意这里的一些答案。 WPF非常适合业务线 (LOB)应用程序。 (青蛙devise的LOB客户端就是最好的例子)。 除了所有的可能性让你的用户界面成为视觉效果(这在商业应用中不是必须的),WPF为你提供了更多的东西。

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

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

我们正在从Windows窗体中重写WPF中的应用程序。 是的,有一个陡峭的学习曲线,你必须“重新学习”一些事情,但它是如此的值得。 结合WCF,我们发现我们正在编写更less的代码,更快,更健壮的比以往任何时候。

坚持一会儿,阅读亚当·纳森的书 ,并看看像Telerik和ComponentOne那样的日益增长的第三方控件库。 我认为一个负面的情况是devise工具Expression Blend使用起来很尴尬。 最新版本仍处于testing阶段,但对于使用Visual Studio多年的人来说,这并不合适。 是的,它主要面向devise师,但是在Visual Studio中你却无法做到。

如果界面devise对你很重要,考虑WPF,因为WPF可以提供更好的UI体验。 但是Windows Forms已经有了多年的发展,所以它已经被certificate是可行的,并且你可以find那个平台上很多精通的程序员。

可移植性也可能是一个问题,WPF只适用于Windows XP SP2以上。

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

那么,一个答案是“当你必须支持1.1或2.0”,因为WPF是.NET 3.0的一部分。 WPF有已知的操作系统限制,并且存在一个明显的技巧问题:如果你有一个知道winform的开发者团队,那么使用 winforms可以更容易地生成健壮的代码。 但是,如果您正在编写大量的UI代码,那么在某个时候可能就会开始拿起WPF了。

WPF也与Silverlight有许多共同之处,所以它具有可转让的好处。

WPF具有很多优点,如超强的数据绑定function,关注点分离,devise和逻辑分离等。

作为一名开发人员,我喜欢使用XAML来定义自己的UI,而不是绑定到Windows Formsdevise人员身上。我知道我可以指望另一位devise师让我的应用看起来不错。

我个人并不在意旧版本的Windows不受支持,但是WPF的一个大问题是Mono( http://www.mono-project.com )并不支持(目前/以往),所以WPF应用程序将无法在Mac OS或Linux上运行。 (Silverlight应用程序将继续)。

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

如果你需要桌面应用程序运行在多个操作系统的棒与SWF。

有很多差异。 我们喜欢WPF:

  1. 编程的声明式风格。
  2. animation和状态转换
  3. Expression Blend是一个很好的工具
  4. 良好的风格支持。

但是,我们坚持使用Windows窗体,因为:

  1. 当他们已经知道Windows窗体时,开发人员需要额外的时间来学习WPF。
  2. WPF将不能在Windows 2000或更低版本上运行。

在决定使用哪一个.NET Framework时,最重要的考虑因素是考虑您的目标受众安装的.NET Framework。 我发现更多的人拥有只支持Windows Forms的较低版本的.NET Framework,但这只是我个人的经验。

WPF的优点是用自定义控件和animation创build漂亮的GUI是非常容易的。 WPF还有助于进一步分离表示层和逻辑层。 如果你有devise师,它可以让你将这项工作的95%集中到非编码器,并允许编码人员在逻辑上工作。 缺点是Expressions Blend的软件成本,以及缺less任何Visual Studio代码分析工具,因为它们往往会陷入框架调用中,试图呈现XAML。 我确信还有其他人,但这是我们真正看到的唯一两个。

主要的考虑是如果你想要求你的客户必须安装.NET 3.0或更好的.NET 3.5 SP1。 你会得到一些非常好的反馈

WPF使得将表单devise工作交给实际的devise师,而不是devise师的服装开发者更容易。 如果这是你想要做的事情,WPF是你的答案。 如果传统的Windows风格的button是好的,那么Windows窗体可能是要走的路。

(如果界面devise“对你很重要”,多个答案会使你声称你应该使用WPF,但是这个界面devise总是“重要的”。)

如果您有MSDN许可证,请查看expression式工具 。 它是为WPF显式devise的,直接导出到Visual Studio,并且可以帮助您轻松转换。

如果你只关心支持Windows,不介意花时间去学习,那就去WPF吧。 它快速,灵活,易于使用,并有很好的工具来处理它。

作为一个附带的奖金,Silverlight是基于WPF的,并且可以让你获得与其他人的技术知识。 如果事情继续以networking为基础,事先知道(和现有代码库)可以轻松传输到浏览器(或Windows Live Mesh),可能会帮助您的软件获得额外的使用寿命。

如果你决定使用WPF,考虑到上面的答案中已经解释过的优点和缺点,我强烈build议与Billy Hollis一起阅读这个dnrTV插曲

在DotNetRocks第315集中 ,Brian Noyes对此进行了广泛的讨论。

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

在过去的3年半中,我一直在做Windows窗体开发(在两家公司)。 这两个应用程序都被广泛使用,最终导致了GDI问题。 大型Windows窗体应用程序最终将耗尽GDI资源 – 导致最终用户不得不重新启动。

Scott抱怨Expression Blend ,作为一名开发人员,他对他来说没有任何意义。 我对Expression Blend的第一反应就是这样。 但是,现在我认为它是一个非常宝贵的工具,但是这取决于你是什么types的开发人员。

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

我也认为在Expression Blend中玩耍,看看吐出来的XAML是学习WPF API的好方法,就像在Windows Forms中使用devise器一样,检查它所吐出的C#代码是很有帮助的在学习如何使用你在那里devise的任何东西。

Expression Blend是有帮助的。 只要尝试一下,特别是如果你正在为应用程序的视觉工作。

马克先前的post引用:

  • 在Windows窗体中,您可以devise用户界面,然后编写代码来驱动该用户界面,该界面通常还包含驱动数据对象的代码。
  • 在WPF中,您投资驱动数据对象的业务层,然后devise一个接口来监听数据对象。

我会争辩说,这是更多的deviseselect,而不是你是否使用Windows窗体或WPF。 但是,我可以理解某些技术可能更适合于某种特定的方法。

只有当你没有WPF的专业知识,你不想投资:)