Windows窗体的大多数限制和技巧对大多数程序员来说都很常见.但是从.NET 3.0开始,还有WPF可用,Windows Presentation Foundation.据说你可以用它来使"性感应用程序"变得更加容易,并且使用.NET 3.5 SP1可以很快地提高执行速度.
但另一方面,很多事情与WPF有所不同.我不会说这更难,但你必须从头开始学习"一切".
我的问题:当你必须创建一个新的GUI并且项目没有时间压力时,是否值得花费额外的时间？
经过三个月的努力,我试图在WPF上敲定一个业务线(LOB)应用程序,我考虑回到我的项目的Windows Forms,并研究其他人的意见,遇到了这个问题......
是的,WPF是一项卓越的技术,它的优势远远超出了仅仅是眼花缭乱......模板和绑定功能就是很好的例子.整个对象模型提供更多灵活性和更广泛的可能性.但是,这并不能成为未来LOB应用程序的事实平台.
WPF在将GUI与业务逻辑分离方面解决的"问题"不是通过简单地从正确的架构和思维模式开始就无法在Windows窗体中轻松解决的问题.甚至WPF的对象路径绑定功能也可以在Windows窗体中使用一些非常简单的辅助类来重现.WPF的数据模板功能非常好,但是在极少数情况下,如果您完全不确切知道在任何给定部分上要表示的对象,那么它们在Windows窗体中无法模拟.屏幕.
Windows Forms竞争的前提是成熟度.你不能在没有某人博客解决Windows窗体问题的博客上摇摆死猫.另一方面,WPF可用的学习资源相对较少,可用的定制控制较少,并且没有解决许多出牙问题.
在制作WPF与Windows Forms决策的高峰期必须是开发环境的成熟.Windows窗体编辑器具有灵活性,响应性和直观性.有关错误的反馈会立即发送给您,解决方案通常很明显,Windows窗体中的compile-> debug-> edit周期非常快.
另一方面,WPF应用程序具有相对可怜的设计时间支持,设计视图在第一次遇到错误时已经准备就绪,在设计人员愿意开始之前通常需要在修复之后进行项目构建再次.从工具箱中拖出组件可能也不受支持,因为它在很多情况下根本不起作用,或者产生完全不直观的结果.尽管有WpfToolkit的承诺,但仍然没有可用于WPF的DataGrid产生任何类型的合理性能或设计时间友好性.
调试WPF应用程序有点像旧的 ASP.NET调试范例...命中F5- >等待 - >启动 - >错误 - >停止 - >修复 - >命中F5- >等待 - >启动 - >错误 - >呻吟 - > stop - > fix - > hit F5....程序运行的所有XAML都被锁定,跟踪XAML特定问题通常很乏味.
简而言之,最重要的是,Windows窗体的开发工具将在WPF应用程序的一小部分时间内打开前端... 特别是如果您要创建主 - 细节网格或电子表格像大多数LOB一样的接口.使用Windows Forms,您可以从已完成90%的工作开始.
我是WPF架构的忠实粉丝.我只是希望设计时工具集不像是一个pre-alpha调试版本.
编辑:这个答案是关于.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 Forms.期.微软并不急于停止使用GDI/Windows Forms平台,因此您可以在未来的公平时间内获得良好的支持.
WPF并不容易掌握,但这不应该是你决定是否投入时间和精力学习WPF的决定.尽管目前还缺乏成熟度,但WPF是围绕一些有用的现代概念构建的.
例如,在WPF中,您对具有良好验证逻辑的精心编写的业务对象的投资是一项可靠的投资.与Windows窗体不同,WPF的数据绑定具有允许接口控件对无效用户输入作出反应而无需编写GUI代码来检测这些错误的功能.这很有价值.
WPF中的样式和模板功能也被证明是有价值的.尽管人们普遍存在一种误解,认为造型和模板的唯一用途是创建屏幕上的视觉效果,但事实是这些功能大大简化了用户界面的编码,提供了丰富的反馈 - 比如禁用/启用自身的按钮基础业务逻辑层的状态,或基于光标下对象状态智能查找其文本的工具提示等.
这些都为"没什么花哨"的业务应用程序添加了非常有价值的功能,仅仅因为它们可以很容易地使接口与底层数据保持一致.
简而言之:
在Windows窗体中,您可以设计用户界面,然后编写代码来驱动该用户界面,该界面通常还包括用于驱动数据对象的代码.
在WPF中,您投资于驱动数据对象的业务层,然后设计一个侦听数据对象的接口.
这是一个看似微妙的差异,但它对您重用代码的能力产生了巨大的影响......这引出了一个问题:"Windows Forms与WPF问题实际上是一个投资决策吗？"
(这似乎成了我最喜欢的主题.)
是否有任何令人信服的理由使用WPF
绝对!WPF绝对令人难以置信!这对几乎任何项目都是一个主要的好处,因为它具有Windows Forms所缺乏的许多功能和能力.
对于商业应用程序,最大的胜利将是:
精彩的数据绑定和模板产生了最大的不同.一旦有了合适的数据模型,只需点击几下即可创建数据模板,并使用Expression Blend通过拖放精确配置对象的外观.绑定到颜色或形状之类的东西是微不足道的.
屏幕布局非常灵活.WPF中的所有内容不仅可以平滑地适应容器大小和形状变化,而且可以轻松地放大和旋转项目,甚至可以扩展到包含框架之外.
普通对象可以以您喜欢的方式呈现,可以在不同的屏幕中轻松地进行不同的演示,可以共享演示,并且可以使其演示适应数据值的变化.
如果需要打印,渲染到打印机是微不足道的.正确配置,WPF使Crystal Reports或SQL Server Reporting Services(SSRS)看起来像一个孩子的玩具.
您的用户界面将看起来更加动态,包括一些很好的功能,例如当您将鼠标移到它们上时为其设置动画的按钮.
对于公用事业和游戏,其他优势成为最重要的:
您可以轻松地向应用程序添加形状,线条和任意图形,而无需使用外部编辑器.这些组件的每个组件都可以是数据绑定和动画,或由代码控制.在Windows窗体中,您通常只需要导入位图并按原样使用它,除非您想要进行大量工作.
动画很酷!用户将会留下深刻的印象,只要你不过分.它们还可以帮助人们了解正在发生的事情并减少对暮光的需求.例如,拖动对象时,您可以为目标设置动画,以显示放下它时会发生什么.
颜色,渐变填充,画笔,花式字体,任何对象的旋转,瓷砖画笔等.任何你想要图形化的东西都是你的要求.
令人难以置信的可定制.我需要为一个应用程序绘制铁轨,所以我可以在它们上面放一列火车.几个小时后,我有了铁轨,我可以使用Bézier曲线在屏幕上的任何地方绘制,他们会自动加入和切换.
最重要的是,您可以在Windows窗体中构建的任何重要大小的GUI都可以在WPF中构建三分之一(或更少)并且看起来更好.
WPF是否需要更多资源(特别是RAM)
与Windows窗体相比,您确实付出了代价,但它很小.
RAM可以上升或下降,具体取决于您的实现.WPF更有效地存储其数据,因此单个对象更小,但WPF中的对象往往比Windows窗体中更多,因此这可以平衡,任何一个都可以提前出现.
与Windows Forms相比,CPU将上升.根据我的经验,屏幕上WPF对象的实际更新所需的CPU大约是普通Windows窗体渲染的两倍.如果您的应用程序花费大部分时间更新屏幕,WPF可能不适合您.但在这种情况下,你可能也没有使用Windows Forms:最严肃的游戏直接写入DirectX.
WPF的磁盘使用率略低,因为它比Windows Forms需要的代码少得多.当然,数据大小相同.
关于CPU使用的另一个注意事项:动画和变换(运动,翻译等)实际上在WPF上比在Windows窗体中更有效,因为它保留了模式存储.这是对象的初始获取速度较慢.
维护费用
在维护方面,WPF是对Windows Forms 的巨大胜利.由于所有内容都以1/5的代码完成,因此维护的数量为1/5.此外,所有样板资料都已消失,因此您可以专注于实际完成工作的代码.
XAML的好处
XAML是WPF的核心.尽管WPF可以在没有XAML的情况下使用,但XAML使其非常易于使用.XAML具有HTML轻松指定用户界面的能力,但其内置标签功能更强大,您可以轻松定义自己的标签.(事实上,这样做是正常的).
XAML的一些特定优点:
您的整个UI都是在一个易于阅读和操作的文本文件中定义的,无论是对用户还是工具
MarkupExtensions允许以清晰简单的方式指定绑定
类型转换器允许轻松指定具有复杂类型的属性.例如,您可以说Brush ="Green",或者您可以指定具有三个停靠点的径向渐变画笔.
您可以创建自己的元素
您可以轻松利用WPF强大的"附加属性"
其他见解
多年来我一直梦想着像WPF这样的东西.许多人已经实现了这部分功能,但要在一个地方以这样的价格(0美元)完成所有功能是惊人的.
WPF是一种从Windows Forms转变的巨大范式,需要一些时间来适应,但是花在学习它上面的时间会让自己付出很多代价.
甚至五年后WPF仍然会有一些疣,但是一旦你体验它,它的力量将彻底打击你.如果有人试图将你拖回Windows窗体,你只会踢和尖叫.
提示: - 获取Expression Blend的副本进行开发 - 偶尔手工编辑XAML - 不要在最初看起来很奇怪时放弃
WPF让你做了一些了不起的事情,我喜欢它......但是每当开发人员问我是否认为他们应该转向新技术时,我总是觉得有资格获得我的建议.
您的开发人员是否愿意(最好是EAGER)花时间学习有效使用WPF？我从来没有想过要对MFC,Windows Forms,甚至是非托管DirectX这么说,但你可能不希望团队试图在普通开发过程中"接收"WPF.运输产品的周期!
至少有一两个开发人员具有一定的设计敏感性,并且拥有最终设计权限的人员对开发问题有一个很好的理解,因此您可以利用WPF功能创建实际上更好的东西,而不仅仅是更"丰富多彩" ,以无偿动画为特色？
您的目标客户群的某些百分比是否运行在可能不支持您计划的功能的集成图形芯片组上 - 或者他们是否仍在运行Windows 2000,这会将客户完全消除？有些人还会问你的客户是否真的关注增强的视觉效果,但是,在90年代早期通过内部公司"我们的商业客户不关心颜色和图片"辩论时,我知道竞争对手精心设计的解决方案会让他们关心,真正的问题是条件是否合适,让你能够提供让他们现在关心的东西.
该项目是否涉及基础开发,至少对于表示层,以避免尝试挂钩到不兼容的传统脚手架的额外复杂性(Interop与Win Forms不是无缝的)？
您的经理可以接受(或分散注意力)开发人员生产力的重要DROP四到六个月吗？
最后一个问题是由于我喜欢将其视为WPF的"FizzBin"性质,有十种不同的方式来实现任何任务,并且没有明显的理由偏向于另一种方法,并且很少有指导可以帮助你制作一个选择.您所做出的任何选择的缺点不仅会在项目的后期很明显,而且几乎可以保证您的项目中的每个开发人员采用不同的方法,从而导致严重的维护问题.当你试图学习框架时,最令人沮丧的是不断绊倒你的不一致.
您可以在我的博客上的条目中找到更多与WPF相关的信息:
http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx
WPF需要Windows Vista或Windows XP SP2,这不是一个繁重的要求,但它是一个相关的要求.如果你想在Windows 2000(有些人仍然这样做)上运行,那么WPF将不适合你.
WPF也是一种较新的技术,并不像Windows Forms那样经过验证,因此您可以选择Windows Forms作为风险较小的选项,特别是对于大型应用程序.
话虽这么说,是的,WPF是未来.Visual Studio 2010正在WPF中重写,它可能是迄今为止最大的WPF应用程序,它也将是该技术的真正测试.
显然,传统的Windows窗体应用程序将是另一种情况,它是正确的选择.
正如其他人所说,无论你走到哪里,都有优点和缺点.正如其他人所说,WPF的优势包括:
能够相对轻松地制作非常丰富的UI .
更轻松的动画和特效
固有的可扩展性(在WPF应用程序和Windows窗体应用程序上使用Windows Vista放大镜工具:请注意,在WPF应用程序中,所有矢量艺术都能很好地扩展)
(OPINION ALERT)我觉得在WPF中使用面向文档的系统"更容易"
但是,WPF存在一些缺点,其中Windows窗体名列前茅:
WPF的内置控件套件比Windows Forms更受限制.
Windows Forms的第三方控制空间得到了更多支持.(当然,这种情况正在发生变化,但请想一想:Windows Forms自2001年开始出现; WPF只用了几年.凭借时间的推移,Windows Forms在社区中得到了更多的支持.)
大多数开发人员已经了解Windows Forms; WPF提供了一种新的学习曲线
最后,请记住,如果您开展工作(或使用正确的第三方工具),您可以在任一工具中创建出色,有吸引力且引人入胜的用户界面.在一天结束时,在所有情况下都不一定更好.使用适合项目的方式.
WPF的编程模型比Windows Forms更加开放和灵活,但与ASP.NET MVC一样,它在正确实现Model-View-ViewModel模式方面需要更多的规则.
我的第一个使用WPF的LOB应用程序最终成为一个彻头彻尾的故障,因为它耗费了资源,使我的终端用户的极低端笔记本电脑停止运转......这最终是因为我刚刚使用WPF + LINQ to SQL并期望得到一个好结果......这就是WPF在Windows Forms中如此强烈分歧的地方......在Windows Forms中,你可以逃避这种事情.WPF在资源上比Windows Forms重得多,如果你没有将你的应用程序设计得精简,你最终会得到一个800磅重的大猩猩.
不要回避WPF ......探索它.但请注意,Windows Forms编码的可接受的错误不会在WPF中产生良好的结果.它们是根本不同的引擎,它们适用于根本不同的编码模式.
最后一句:如果您继续使用WPF,请熟悉数据虚拟化,以便与列表和网格一起使用.什么是简单的数据绑定ListItem或GridCell最终成为WPF中的一个重要的逻辑+可视对象 - 图形,如果您不学习如何虚拟化,您的应用程序将无法在大型数据集上表现良好.
WPF有一个非常陡峭的学习曲线,我建议你首先获得明显的书籍(Adam Nathan, Sells/Griffiths和 Chris Anderson)和博客(Josh Smith等).为此做好准备,并确保您的项目让您有时间学习WPF.
除了学习该技术之外,还要花些时间学习用于构建WPF应用程序的模式.模型视图ViewModel(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客户端就是最好的例子).除了让您的用户界面显眼的可能性(在商业应用程序中不是必需的)之外,WPF还为您提供了更多功能.
数据绑定和模板功能仅优于Windows窗体.它还提供了一种更好的分离代码和表示的方法.我们已经成功地将WPF用于2个LOB应用程序,团队成员不超过2-3个.
您将面临的最大问题可能是WPF的陡峭学习曲线(与Windows Forms相比),这将降低与不习惯WPF的开发人员的开发速度.
我们目前正在从Windows Forms重写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上运行.(Altough Silverlight应用程序将).
如果您有时间和资源投资学习WPF,那就去做吧!即使你要编写Silverlight应用程序来支持多个操作系统.
如果您需要桌面应用程序在多个操作系统上运行SWF.
有很多不同之处.我们喜欢WPF:
编程的声明式风格.
动画和状态转换
Expression Blend是一个很棒的工具
良好的风格支持.
但是,我们坚持使用Windows Forms,因为:
开发人员在已经了解Windows窗体时学习WPF所需的额外时间.
WPF不能在Windows 2000或更低版本上运行.
决定使用哪一个时,最重要的考虑因素是考虑目标受众安装的.NET Framework.我发现更多的人拥有只支持Windows Forms的较低.NET Framework版本,但这只是我的个人经验.
WPF的优点是使用自定义控件和动画创建外观漂亮的GUI要容易得多.WPF还有助于进一步显示表示层和逻辑层.如果你有设计师,它允许你将这项工作的95%用于非编码器,并允许编码人员处理逻辑.缺点是Expressions Blend的软件成本,以及缺少任何Visual Studio代码分析工具都运行良好,因为它们在尝试渲染XAML时往往会陷入框架调用中.我相信还有其他人,但这些是我们真正看到的唯一两个.
主要考虑因素是您是否希望您的客户必须安装.NET 3.0或更好的.NET 3.5 SP1.你会得到一些反复的反馈
WPF使表单设计工作更容易交给真正的设计师,而不是设计师服装的开发人员.如果那是你想做的事情,那么WPF就是你的答案.如果经典的Windows样式按钮很好,那么Windows Forms可能就是这样.
(如果界面设计"对你很重要",那么多个答案会声称您应该使用WPF,但这很模糊.界面设计总是"重要的".)
京公网安备 11010802040832号 | 京ICP备19059560号-6 