在创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相关信息：
经过三个月的努力，在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：
- 编程的声明式风格。
- animation和状态转换
- Expression Blend是一个很好的工具
- 良好的风格支持。
但是，我们坚持使用Windows窗体，因为：
- 当他们已经知道Windows窗体时，开发人员需要额外的时间来学习WPF。
- 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的专业知识，你不想投资:)
