关于wpf:我的C#.NET团队是否应该迁移到Windows Presentation Foundation?

关于wpf:我的C#.NET团队是否应该迁移到Windows Presentation Foundation?

Should my C# .NET team migrate to Windows Presentation Foundation?

我们为商业银行提供基础设施服务(数据检索和存储)和小型智能客户端应用程序(主要是花式报告)。 我们的团队是由C#.NET程序员组成的庞大的40名零碎合同工。 我们支持已开发的50多种应用程序和系统。

团队中的一些成员开始制作基于WPF,WF和WCF的应用程序。 由于他们是第一位,大多数成员都不了解这些技术。 他们带来了哪些好处,可以克服重新培训团队的成本?


我们刚刚结束了一个项目,在这个项目中我自己和其他4个人开发了一个相当成功的分布式企业应用程序。我们开始使用Win32,然后在第一次迭代后切换到WPF,以满足可用性专家的需求。这是我的经验。

WPF具有一些非常非常好的功能。通常,它使琐碎的事情变得微不足道(例如,创建显示丰富的演示数据的列表框,例如与表格混合的图像,副本等),但反过来又可以使"这在Win32中非常容易"痛苦的令人沮丧。我已经在WPF工作了6个月了,但我仍然发现将组合框与XML数据绑定到数据提供了令人恐惧的体验。

如前所述,WPF具有一些很棒的绑定。我喜欢如何使用XPath绑定到XML文档或行内片段,但是我讨厌仅在双向绑定的情况下才能使用内置绑定验证(而且我讨厌如何不能强制使用内置的绑定验证,即使数据不在某些业务规则的范围内,也可以将用户输入传递回对象。

WPF的学习曲线很大。它甚至不是曲线-它是一堵墙。这是一个艰难的过程。这是使用Windows演示文稿的完全不同的方式,无论如何,对我而言,在我开始感到有些自在之前,它需要大量阅读和播放。这不是世界上最简单的事情,但是它允许您做一些令人难以置信的强大工作(例如,在我们的项目中,我创建了一个表单引擎,该表单引擎使用大约300行XSLT从XML创建了完整的XAML表单-完整的绑定和验证功能)。

总的来说,尽管学习过程很复杂,所有这些都有些错误,并且有些深深的挫败感,但我对我们选择XAML感到非常满意。积极的因素远大于消极的因素,它使我们能够做一些我认为不可能的事情,而不会对性能造成巨大的打击。

如果您决定走WPF路线,我强烈建议您阅读以下两本书:

  • 由Adam Nathan撰写的Windows Presentation Foundation Unleashed是一个很棒的介绍,色彩丰富!它看起来像一个博客,并为您提供了一个很棒的介绍-http://www.amazon.ca/Windows-Presentation-Foundation-Unleashed-WPF/dp/0672328917/ref=pd_ys_iyr3

  • 编程WPF:使用Windows Presentation Foundation构建Windows Ui,作者是Chris Sells。有关WPF发行的更多细节和一本好书-http://www.amazon.co.uk/Programming-WPF-Building-Presentation-Foundation/dp/0596510373

祝好运!


WPF UI比当前的C#替代方案更易于设计实现和维护,因此,如果您的代码库中有很多负责处理UI,则迁移可能会有所帮助-例如,您会发现您的团队将节省处理其UI的时间。 UI层。如果您的大部分代码是业务逻辑,那么它对您的帮助不大。


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

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

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

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

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

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

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

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

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


WPF:

  • 都是关于图形的!
  • 是一个与分辨率无关的框架(意思是-WPF完全采用了矢量图形的概念-并使位图图形的缩放成为一个沉思的过程)
  • 硬件加速了!!! WPF图形在可能的情况下可以通过Direct3D进行硬件加速-它不是基于GDI的!
  • 没有Paint()功能-WPF基于保留的图形模式/基于树的绘图系统。最后!
  • 图形非常动态-所有内容都可以动画-动画内置在框架中。记住...。没有Paint()
  • 高度可定制-尽管进入ControlTemplates的实质是复杂化的开始。您只需将对象添加到显示树中,然后让WPF担心更新。
  • 具有非常丰富的文本渲染功能。
  • 希望通过使用用于图形定义的声明性语言(XAML)和复杂的GUI设计软件(Expression Blend)来改善设计人员/编码人员的工作流程。尽管重要的是要意识到,可以以声明性方式完成的任何事情也可以在代码中完成。 WPF的复杂性已经吓退了许多设计人员,这也是有争议的,但是它为编码人员提供了一个强大的框架。

WPF:

  • 不是Windows Forms ++-完全是一个完全不同的概念
  • 不是Silverlight-Silverlight是WPF的子集。相当轻的子集。
  • 不是MFC-确定,这很明显
  • 在Windows XP中不容易分发-这是一个耻辱,也许是其最大的失败之一
  • 不是XAML。这种区别需要理解。 XAML是一种可选的声明性语言,可以在WPF应用程序的开发过程中使用。尽管一经理解,它绝对不是必需的组件,它绝对可以改善复杂图形框架的工作流程,设计和重构。

WPF与Windows Forms根本不同。这意味着您的团队需要进行大量的培训。


WPF是UI方法论中的当前"最新技术"。如果人们正在学习编写UI(而不是相对类似的GDI,Win32和后来的WinForms),它就可以使用了,学习它的时间不会太长。您可能会认为它就像切换到Dvorak键盘一样-最困难的部分是改变您对自己熟悉的UI设计的思考。

也就是说,您至少应该鼓励团队成员在业余时间尝试WPF。从一开始就使资源可用,也许通过以下方式:

  • 有指向一些页面的链接,这些页面告诉您要使用WPF进行安装需要安装的内容-如果未提及Blend,那么我将不信任它。
  • 在这里查找"入门"问题,因为他们可能会从经验丰富的个人那里得到很好的答案。
  • 至少购买几本好书,并让人们根据需要借用。

WPF是一种非常新颖的UI设计方法。唯一的问题是,它引入了大量概念,其中一些概念只是为了掩盖XAML(XML)的冗长性。它也受建筑宇航员设计的影响,但总的来说我对此很满意。它使您以前无法拒绝的事情变成了可以管理的事情。


一开始我不确定,大多数应用程序似乎都很滞后(当然,WinForms的运行速度也不快)。 .NET 3.5 SP1似乎已修复了该问题,他们在其中集成了多种技术的硬件加速。

集成的动画/情节提要/矢量功能非常好,并且朝着正确的方向迈出了一步。如果您对Expression Blend有所了解,则可以很快地对应用程序进行原型制作。我认为这些都是明显的好处。

从长远来看,我认为WinForms和较旧的技术不是可持续的选择。

还有Adobe Flex,Adobe / Macromedia,因为他们具有Flash方面的经验,因此在更强大和"令人兴奋"的GUI解决方案方面经验丰富。

我只是希望我们最终不要在台式机上安装10个不同的VM只是为了运行所有这些不同的框架...

回覆:

fancy reporting

幻想可能是WPF的优势之一...


我认为您最初提出的问题的关键词是"幻想"。如果您的客户确实希望交付的产品有很多亮点,那么转换到WPF确实可以带来一些好处。


推荐阅读