创建新的GUI时,WPF是Windows窗体的首选吗?

时间:2020-03-05 18:51:55  来源:igfitidea点击:

Windows窗体的大多数限制和技巧对大多数程序员来说都是常见的。但是从.NET 3.0开始,Windows Presentation Foundation也提供了WPF。据说我们可以使用它使"性感的应用程序"更容易,并且使用.NET 3.5 SP1可以大大提高执行速度。

但是另一方面,WPF的许多工作也有所不同。我不会说这比较困难,但是我们必须从头开始学习"一切"。

我的问题:当我们必须创建一个新的GUI并且项目没有时间压力时,花这些额外的时间值得吗?

解决方案

回答

如果我们只关心支持Windows而又不介意学习它,那么请使用WPF。它快速,灵活,易于重新涂饰,并且具有出色的工具可以使用。

回答

我认为值得学习WPF。一旦掌握了速度,恕我直言,在表单上进行设计工作就容易得多。我不会为"性感"的东西担心的那么多。其中大多数只是一种时尚。我们可以在WPF中快速,轻松地制作"正常"的Winforms样式的应用程序。

整个概念使其易于设计IMO。

回答

WPF的学习曲线非常陡峭,我建议我们先阅读一些显而易见的书(Adam Nathan,
卖出/格里菲思,以及
克里斯·安德森(Chris Anderson)和
博客(乔什·史密斯(Josh Smith)等)。只要为此做好准备,并确保项目可以让我们有时间学习WPF。

除了学习技术之外,还要花一些时间来学习用于构造WPF应用程序的模式。模型视图ViewModel(MVVM)似乎已经获得了广泛的认可。

就个人而言,我认为WPF是值得的,但应该事先警告。还要注意,我们实际上限制了用户使用Windows XP SP2 +和WindowsVista。我们已经做出了决定,但是我们可能有一些不同的要求。

回答

如果我们具有MSDN许可证,请签出表达式工具。它是专门为WPF设计的,可以直接导出到Visual Studio,并且可以轻松过渡。

回答

当前,我们正在从Windows窗体在WPF中重写我们的应用程序。是的,学习曲线很陡,我们必须"重新学习"一些东西,但这是值得的。与WCF结合使用,我们发现与以往相比,我们正在编写的代码更少,速度更快,功能更强大。

坚持一会儿,阅读Adam Nathan的书,并查看不断增长的第三方控件库,例如Telerik和ComponentOne的控件。我认为,有一个缺点是设计工具Expression Blend使用起来很尴尬。最新版本仍处于测试阶段,但对于使用Visual Studio多年的我们来说,感觉并不正确。是的,它主要是针对设计师的,但是有些事情是我们在Visual Studio中无法做到的。

回答

作为附带的好处,Silverlight基于WPF,从任何一个开始,我们都可以了解如何与其他人一起工作。如果事情继续以网络为基础,那么具有先验知识(和现有代码库)可以轻松地传输到浏览器(或者Windows Live Mesh),可能会帮助软件获得更多的生命。

回答

如果我们决定使用WPF,考虑到以上答案中已经说明的利弊,我强烈建议与Billy Hollis一起进行dnrTV节目

回答

WPF使我们能够做一些令人惊奇的事情,而我喜欢它……但是,每当开发人员问我是否认为他们应该转向新技术时,我总是有义务限制我的建议。

开发人员是否愿意(最好是EAGER)花费时间学习有效使用WPF?我从没想过要对MFC,Windows Forms甚至是不受管理的DirectX这么说,但是我们可能不希望团队在正常开发过程中尝试"挑选" WPF。循环运输产品!

开发人员中至少有一两个是否具有一定的设计敏感性,并且拥有最终设计权的个人对开发问题是否有体面的了解,因此我们可以利用WPF功能来创建实际上更好的东西,而不是仅仅使它们变得"丰富多彩" ,具有免费动画?

目标客户群中有一定百分比的运行在可能不支持我们正在计划的功能的集成图形芯片组上吗?还是它们仍在运行Windows 2000,从而完全将它们淘汰了?有人还会问客户是否真正关心增强的视觉效果,但是在90年代初期,通过内部公司生活的"我们的业务客户不在乎颜色和图片"的辩论,我知道竞争对手精心设计的解决方案将使他们得到照顾,而真正的问题是条件是否合适,以便我们提供可以使他们现在得到照顾的东西。

该项目是否至少在表示层涉及基础开发,以避免尝试陷入不兼容的旧式脚手架的额外复杂性(与Win Forms互操作不是无缝的)?

经理可以在四到六个月内接受(或者不注意)开发人员生产力方面的重大下降吗?

最后一个问题是由于我想将其视为WPF的" FizzBin"性质,用十种不同的方式来执行任何任务,没有明显的理由偏爱一种方法而不是另一种方法,并且几乎没有什么指南可以实现选择。我们做出的任何选择的缺点不仅会在项目后期更明显,而且几乎可以保证项目中的每个开发人员都采用不同的方法,这会导致严重的维护麻烦。最令人沮丧的是,在我们尝试学习框架时,不断引起不一致。

我们可以在我的博客中的条目中找到更多与WPF相关的深入信息:

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

回答

斯科特(Scott)抱怨Expression Blend,以及它对开发人员的意义如何。我对Expression Blend的第一反应就是这样。但是,现在我将其视为宝贵的工具,但这实际上取决于我们是哪种类型的开发人员。

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

我还认为,在Expression Blend中玩转并查看被吐出的XAML是学习WPF API的绝佳方法……就像在Windows Forms中使用设计器并检查其吐出的Ccode一样,对学习如何使用我们在此处设计的内容。

Expression Blend很有帮助。只需尝试一下,特别是如果我们正在处理应用程序的视觉效果。

回答

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

回答

WPF通过XAML对声明性UI的支持,丰富的控件模板和样式以及诸如Expression Blend之类的工具,使设计师与同一个项目的开发人员合作的能力大大提高。另外,它为开发人员提供了添加的依赖属性和极其强大的数据绑定的灵活性。另外,Silverlight支持XAML的子集以及与WPF相同的控件类,因此我们可以轻松地将应用程序移植为RIA。

我会选择WPF代替Windows Forms。即使目标计算机仅具有.NET 2.0,如果用户可以安装其他程序,新的.NET Framework Client配置文件也使部署WPF应用程序变得非常容易。

我可能决定坚持使用Windows Forms的唯一原因是,该产品是否将部署在已锁定且仅具有.NET 2.0或者.NET 1.1的计算机上。

回答

WPF的优势在于,使用自定义控件和动画来创建美观的GUI更加容易。 WPF还有助于进一步分离表示层和逻辑层。如果我们有设计师,则可以将95%的工作分配给非编码人员,并允许编码人员进行逻辑处理。缺点是Expressions Blend的软件成本,并且缺少任何运行良好的Visual Studio代码分析工具,因为它们往往会陷入尝试渲染XAML的框架调用中。我敢肯定还有其他人,但这是我们真正看到的仅有的两个人。

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

回答

有许多不同之处。我们之所以喜欢WPF,是因为:

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

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

  • 当开发人员已经了解Windows窗体时,他们需要花费额外的时间来学习WPF。
  • WPF将无法在Windows 2000或者更低版本上运行。

回答

正如其他人所说,无论我们选择哪种方式,都有其优点和缺点。正如其他人所说,WPF的优点包括:

  • 相对容易地制作非常丰富的UI的能力。
  • 更轻松的动画和特效
  • 固有的可伸缩性(在WPF应用程序和Windows Forms应用程序上使用Windows Vista放大镜工具:请注意,在WPF应用程序中,所有矢量插图的缩放比例都很漂亮)
  • (观点提醒)我觉得在WPF中进行面向文档的系统"更轻松"

但是,WPF有一些缺点,其中Windows窗体排在首位:

  • WPF的内置控件套件比Windows Forms的套件要受限制得多。
  • Windows窗体的第三方控件空间中有更多支持。 (当然,这种情况正在发生变化,但是请考虑一下:Windows Forms自2001年就诞生了; WPF才几年。借助时间,Windows Forms在社区中获得了更大的支持。
  • 大多数开发人员已经知道Windows窗体。 WPF提供了新的学习曲线

最后,请记住,如果我们进行这项工作(或者使用正确的第三方工具),则可以在任一工具中创建出色,有吸引力且引人入胜的UI。归根结底,这两种情况都不一定在所有情况下都更好。使用适合项目的感觉。

回答

WPF需要WindowsVista或者Windows XP SP2,这不是一个繁重的要求,但这是一个相关的要求。如果我们想在Windows 2000上运行(某些人仍然可以运行),那么WPF将不适合我们。

WPF也是一种较新的技术,没有Windows窗体那么成熟,因此我们可以选择Windows窗体作为一个风险较小的选项,特别是对于大型应用程序。

话虽这么说,WPF是未来。 Visual Studio 2010正在用WPF重写,这可能是迄今为止最大的WPF应用程序,它也是对该技术的真实测试。

显然,旧的Windows Forms应用程序将是另一种正确选择的情况。

回答

两种技术各有利弊。在具有"经典" UI的大型应用程序中,我将使用Windows窗体。在需要丰富用户界面(皮肤,动画,更改用户界面)的应用程序中,我将选择WPF。请检查WPF与Windows窗体比较WPF和Windows窗体。

回答

如果界面设计对我们很重要,请考虑使用WPF,因为WPF可以提供更好的UI体验。但是Windows Forms具有多年的发展历史,因此它被证明可以工作,并且我们可以找到许多精通该平台的程序员。

另外,可移植性可能是一个问题,WPF仅适用于WindowsXP SP2及更高版本。

此外,WPF具有陡峭的学习曲线,这意味着在没有特定的WPF经验的情况下交付高质量的产品并不容易。

回答

好的,一个答案是"何时必须支持1.1或者2.0",因为WPF是.NET 3.0的一部分。 WPF存在已知的OS限制,并且存在一个明显的技能问题:如果我们拥有一支熟悉winforms的开发人员团队,那么使用winforms生成可靠的代码可能会更容易。但是,如果我们要编写大量的UI代码,则可能值得在某个时候开始使用WPF。

WPF与Silverlight也有很多共同点,因此具有可转让的好处。

回答

WPF使将表单设计工作移交给实际设计师而不是设计师服装开发人员变得容易得多。如果我们想这样做,那么WPF就是答案。如果经典的Windows样式按钮没问题,那么Windows Forms可能是可行的方法。

(有多个答案表明,如果接口设计"对我们来说很重要",则应该使用WPF,但这很含糊。接口设计总是"重要"的。)

回答

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

作为开发人员,我喜欢使用XAML而不是XAML定义UI的能力。
与Windows Forms Designer紧密结合,我感到很高兴,我可以指望
让我的应用看起来不错。

就我个人而言,我不在乎不支持较旧版本的Windows,
但是WPF的一大问题是(当前/永远)不支持
由Mono(http://www.mono-project.com)提供,因此WPF应用程序将无法在Mac OS或者Linux上运行。
(Altough Silverlight应用程序将)。

如果我们有时间和资源来学习WPF,那就去做吧!
即使我们要编写Silverlight应用程序以支持多个OS。

如果我们需要桌面应用程序在SWF上的多个操作系统上运行。

回答

我不同意这里的一些答案。 WPF确实非常适合业务线(LOB)应用程序。 (青蛙设计的LOB客户端就是最好的例子)。除了使UI变得令人眼花candy乱(在业务应用程序中不需要)之外,WPF还为我们提供了更多功能。

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

我们将面临的最大问题可能是WPF(与Windows Forms相比)陡峭的学习曲线,这将降低不熟悉WPF的开发人员的开发速度。

回答

对于转换项目(来自Visual Basic 6.0),很难让团队切换到WPF。除了学习曲线之外,人们已经习惯了旧的界面。 Windows窗体尽管已被逐步淘汰,但仍将存在很长时间。

回答

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

回答

经过三个月的尝试,在WPF上推出了业务线(LOB)应用程序之后,我想到了要考虑将Windows Forms用于我的项目,并在研究其他人的意见时遇到了这个问题。

是的,WPF是一项出色的技术,它所具有的优势远远超出了单纯的糖果……模板和绑定功能就是很好的例子。整个对象模型提供了更大的灵活性和更广泛的可能性。但是,这并不能使其成为将来的LOB应用程序的实际平台。

WPF在将GUI与业务逻辑分离方面解决的"问题",并不是简单地从正确的体系结构和思维方式入手就可以在Windows Forms中轻松解决的问题。甚至WPF的对象路径绑定功能都可以在Windows Forms中通过一些非常简单的帮助程序类进行复制。 WPF的数据模板功能非常出色,但是当我们完全不确切知道要在对象的任何给定部分表示什么对象时,在很少有的情况下我们就无法在Windows Forms中模拟它们屏幕。

在成熟度方面,Windows Forms领先的地方。我们不能在Google上摆出一只死猫,除非我们访问某些博客,那里有人为我们解决了Windows Forms问题。另一方面,WPF具有相对较少的学习资源,较少的自定义控件,并且没有解决许多繁琐的问题。

在WPF与Windows Forms之间做出决策的最高点必须是开发环境的成熟度。 Windows窗体编辑器流畅,响应迅速且直观。有关错误的反馈会立即获得,解决方案通常很明显,并且Windows Forms中的compile-> debug-> edit周期非常快。

另一方面,WPF应用程序具有相对可怜的设计时间支持,在第一次遇到错误时,设计视图就已经完全准备就绪,通常需要在修复之后进行项目构建,然后设计人员才愿意加入。再次。考虑到在很大的情况下它根本无法工作或者产生完全不直观的结果,也可能不支持从工具箱中拖放组件。尽管WpfToolkit承诺了,但WPF仍然没有可用的DataGrid能够产生任何合理的性能或者设计时间友好性。

调试WPF应用程序有点像旧的ASP.NET调试范例...击F5->等待->启动->错误->停止->修复->击F5->等待->启动->错误-> gro吟->停止->修复->击F5.

简而言之,最重要的是,Windows窗体的开发工具将使我们在WPF应用程序的一小部分时间内就能达到前端水平……尤其是在创建主从网格或者电子表格时大多数LOB都具有的接口。使用Windows Forms,我们可以先完成90%的工作。

我是WPF体系结构的忠实拥护者。我只是希望设计时工具集不像是pre-alpha调试版本。

编辑:此答案发布有关.NET 3.5 + VisualStudio2008,但带有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的编程模型比Windows Forms更为开放和灵活,但是与ASP.NET MVC一样,在正确实现Model-View-ViewModel模式方面,它需要更多的纪律。

我的第一个使用WPF的LOB应用程序最终以失败告终,因为这是一种资源消耗,最终使我的最终用户的超低端笔记本电脑停顿了……这最终是因为我只是对WPF +感兴趣LINQtoSQL并预期会有良好的结果...这就是WPF与Windows Forms如此巨大的区别...在Windows Forms中,我们可以摆脱这种情况。 WPF在资源上比Windows Forms重得多,并且如果不将应用程序设计为精简的,最终将产生800磅的大猩猩。

不要回避WPF ...探索它。但是请注意,Windows Forms编码可接受的错误不会在WPF中产生良好的结果。它们是根本不同的引擎,因此它们会导致根本不同的编码模式。

硬道理:如果我们确实要使用WPF,那么我们将非常熟悉与列表和网格一起使用的数据虚拟化。在WPF中,什么是简单的数据绑定ListItem或者GridCell最终成为笨拙的逻辑+可视对象图,并且,如果我们不学习如何进行虚拟化,则应用程序在大型数据集上的性能将不佳。

回答

除了UI设计的灵活性外,WPF还具有一些技术优势:

1.)WPF不依赖GDI对象。好吧,我认为它为窗口本身的实例使用了2个GDI对象,但这几乎没有。在某种程度上,我参与了一个非常大的Windows Forms内部应用程序。我们办公室的人有时会同时运行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作为业务演示平台的经验。

总的来说,我在上面所做的评论仍然有效。WPF的设计时间支持尚未发布。如果我们急于推出富客户端应用程序,请使用Windows Forms。时期。 Microsoft并不急于中断GDI / Windows Forms平台,因此我们可以指望在将来的相当长的时间内获得良好的支持。

WPF并不容易掌握,但这不应该成为我们是否要花费时间和精力来学习WPF的决心。尽管WPF目前尚不成熟,但它还是围绕一些有用的现代概念构建的。

例如,在WPF中,我们对具有良好验证逻辑的,编写良好的业务对象的投资是一项可靠的投资。与Windows Forms不同,WPF的数据绑定功能丰富,可以使界面控件对无效的用户输入做出反应,而无需编写GUI代码来检测这些错误。这是很有价值的。

事实证明,WPF中的样式和模板功能也很有价值。尽管常见的误解是样式和模板的唯一用途是创建屏幕上的糖果,但事实是,这些功能大大简化了用户界面的编码,从而提供了丰富的反馈,例如基于按钮禁用/启用自身的按钮。基础业务逻辑层的状态,或者根据光标下对象的状态智能地找到其文本的工具提示等。

所有这些都为"没什么花哨的"业务应用程序添加了极为宝贵的功能,仅因为它们使保持接口与基础数据的一致性变得容易。

简而言之:

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

这看似细微的差别,但是在重用代码的能力上却产生了巨大的差别……这引出了一个问题:" Windows Forms vs WPF问题实际上是一项投资决定吗?"

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

回答

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

绝对地! WPF绝对不可思议!对于几乎所有项目来说,这都是一个主要的好处,因为它具有Windows Forms所缺乏的众多功能。

对于商业应用而言,最大的成功将是:

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

对于实用程序和游戏,其他优势排在前列:

  • 我们可以轻松地在应用程序中添加形状,线条和任意图形,而无需使用外部编辑器。其中的每个组件都可以进行数据绑定和动画处理,或者由代码控制。在Windows窗体中,通常我们只需导入一个位图并按原样使用它,除非我们想进行很多工作。
  • 动画很棒!只要我们不对用户留下深刻的印象,它就会给我们留下深刻的印象。它们还可以帮助人们了解正在发生的事情并减少照明需求。例如,拖动对象时,可以为目标设置动画以显示如果将其放下会发生什么。
  • 颜色,渐变填充,画笔,花式字体,任何对象的旋转,平铺画笔等。图形上想要的任何东西都是我们要的。
  • 可定制的。我需要为一种应用绘制铁轨,所以我可以在它们上放火车。几个小时后,我有了铁轨,可以使用Bzier曲线在屏幕上的任何位置绘制它们,它们会自动合并并切换。

最重要的是,我们可以在WPF中构建我们可以在Windows窗体中构建的任何大尺寸的GUI,只需花费三分之一(甚至更少)的努力,并且外观就会更好。

WPF是否需要更多资源(尤其是RAM)

与Windows窗体相比,我们确实要付出一定的代价,但这只是一个小数目。

  • RAM可能会上升或者下降,具体取决于实现。 WPF可以更有效地存储其数据,因此单个对象较小,但是WPF中的对象往往比Windows窗体中的对象更多,因此这种平衡可以解决,任何一个都可以领先。
  • 与Windows窗体相比,CPU将上升。以我的经验,屏幕上WPF对象的实际更新所需的CPU大约是普通Windows Forms渲染的两倍。如果应用程序花费大部分时间来更新屏幕,则WPF可能不适合我们。但是在那种情况下,我们可能也不会使用Windows窗体:大多数严肃的游戏都是直接编写到DirectX的。
  • WPF的磁盘使用量将略少一些,因为与Windows窗体相比,它占用的代码少得多。当然,数据大小将相同。

关于CPU使用的另一注:动画和变换(运动,平移等)实际上在WPF上比Windows窗体更有效,因为它保留了模式存储。最初到达那里的对象较慢。

维护费用

在维护方面,WPF是Windows Forms的巨大胜利。由于所有工作都是在以前的1/5的代码中完成的,因此需要维护的代码数量是在1/5之前。再加上所有样板工作都一去不复返了,因此我们可以专注于实际完成工作的代码。

XAML的好处

XAML是WPF的核心。尽管可以在不使用XAML的情况下使用WPF,但是XAML使其易于使用。 XAML具有HTML的功能,可以轻松指定用户界面,但是其内置标记功能强大得多,并且我们可以轻松定义自己的标记。 (实际上,这样做是正常的)。

XAML的一些特定优点:

  • 整个用户界面都在一个文本文件中定义,该文本文件对于用户和工具均易于阅读和操作
  • MarkupExtensions允许以清晰,简单的方式指定绑定
  • 通过类型转换器,可以轻松指定具有复杂类型的属性。例如,我们可以说Brush =" Green",也可以指定带有三个停止点的径向渐变画笔。
  • 我们可以创建自己的元素
  • 我们可以轻松利用WPF强大的"添加属性"

其他见解

多年以来,我一直梦想着像WPF这样的东西。许多人已经实现了此功能的某些部分,但是以一个这样的价格(0美元)将所有功能集中到一个地方却令人惊讶。

WPF是Windows窗体的巨大转变,需要一定的习惯,但是花在学习上的时间将使自己获得很多回报。

WPF甚至在五年后仍然有一些缺陷,但是一旦我们体验到它,它的力量将完全震撼我们。如果有人试图将我们拖回Windows窗体,我们只会踢脚而尖叫。

尖端:
获得一份Expression Blend进行开发的副本
偶尔手动编辑XAML
一开始看起来很奇怪就不要放弃

回答

在过去的3.5年中,我一直在进行Windows Forms开发(在两家公司中)。两种应用程序都被广泛使用,最终出现GDI问题。大型Windows窗体应用程序最终将耗尽GDI资源,从而导致最终用户必须重新启动。

回答

马克在以前的帖子中的一句话:

In Windows Forms you design your user interface, then write code to drive that user interface, which generally also includes code to drive your data objects.
  In WPF you invest in the business layer that drives your data objects, then design an interface that listens to your data objects.

我认为这更多是一种设计选择,而不是我们是否使用Windows Forms或者WPF。但是,我可以理解,某些技术可能更适合于特定方法。

回答

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

回答

仅当我们不具备WPF专业知识并且不想对其进行投资时:)

回答

我将Winforms用于概念证明的快速证明,因为尽管它对于实际应用程序来说很糟糕,但对于" Visual Basic 6.0"样式的快速原型设计却非常有用。

因此,这里有一个例子:

如果我需要遍历一个过程的多个步骤(例如下载某些内容,计算/转换,创建智能输出)并使所有内容都可重现,那么我通常会制作一个带有ListBox和几个按钮的快速表单。

由于我是一名REAL开发人员,因此逻辑将已经在视图之外的其他类中,因此这是一个很好的起点。