小智 23
我们正在完成一个项目,我和其他4个项目开发了一个相当成功的分布式企业应用程序.我们开始使用Win32,然后在第一次迭代后切换到WPF以满足我们的可用性专家的需求.这是我的经历.
WPF有一些非常非常棒的功能.一般来说,它使真正困难的事情变得微不足道(例如创建显示丰富的演示数据的列表框,例如混合了表格,副本等的图像),但反过来又可以使"在Win32中过去这么容易"痛苦地沮丧.我已经在WPF工作了6个月了,我仍然发现将组合框数据绑定到XML数据提供者是一种可怕的经历.
正如我上面提到的那样,WPF有一些很好的,不那么好的约束力.我喜欢你如何使用XPath绑定到XML文档或内联片段,但我讨厌如果你的绑定是双向的,你怎么只能使用内置的绑定验证(我更加讨厌你怎么不强迫内置绑定验证,将用户输入传递回对象,即使数据超出某些业务规则的范围).
WPF有一个巨大的学习曲线.它甚至不是曲线 - 它是一堵墙.这是一个艰难的过程.这是一种完全不同的Windows演示方式,对我而言,在我开始觉得有些舒服之前,它需要大量的阅读和演奏.这不是世界上最简单的东西,但它允许你做一些非常强大的东西(例如在我们的项目中,我创建了一个表单引擎,使用大约300行XSLT从XML创建完整的XAML表单- 完整的绑定和验证).
总的来说,我非常满意我们选择了XAML,尽管它有学习曲线,有点儿错误,以及一些深深的挫折.积极因素远远超过了负面因素,它让我们做了一些我认为不可能没有对表现造成极大打击的事情.
如果你决定走WPF的路线,我强烈推荐这两本书:
由Adam Nathan发布的Windows Presentation Foundation是一个很棒的介绍,全彩色!它读起来就像一个博客,给你一个伟大的介绍 - http://www.amazon.ca/Windows-Presentation-Foundation-Unleashed-WPF/dp/0672328917/ref=pd_ys_iyr3
编程WPF:使用Windows Presentation Foundation构建Windows Ui,由Chris Sells编写.WPF Unleashed附带更多细节和一本好书 - http://www.amazon.co.uk/Programming-WPF-Building-Presentation-Foundation/dp/0596510373
祝好运!
Lor*_*gal 15
WPF UI比当前的C#替代品更容易设计实现和维护,所以如果你的很多代码库负责处理UI,那么迁移可能会有益 - 比如,你会发现你的团队会节省处理他们的时间UI层.如果您的大部分代码都是业务逻辑,那么它将无济于事.
小智 12
WPF让你做了一些了不起的事情,我喜欢它......但是每当开发人员问我是否认为他们应该转向新技术时,我总是觉得有资格获得我的建议.
您的开发人员是否愿意(最好是EAGER)花时间学习有效使用WPF？我从来没有想过要对MFC,Windows Forms,甚至是非托管DirectX这么说,但你可能不希望团队试图在普通开发过程中"接收"WPF.运输产品的周期!
至少有一两个开发人员具有一定的设计敏感性,并且拥有最终设计权限的人员对开发问题有一个很好的理解,因此您可以利用WPF功能创建实际上更好的东西,而不仅仅是更"丰富多彩" ,以无偿动画为特色？
您的目标客户群的某些百分比是否运行在可能不支持您计划的功能的集成图形芯片组上 - 或者他们是否仍在运行Windows 2000,这会将客户完全消除？有些人还会问你的客户是否真的关注增强的视觉效果,但是,在20世纪90年代早期经历了内部公司"我们的商业客户并不关心颜色和图片"的辩论时,我知道竞争对手精心设计的解决方案将会让他们关心,真正的问题是条件是否正确,让你能够提供让他们现在关心的东西.
该项目是否涉及基础开发,至少对于表示层,以避免尝试挂钩到不兼容的传统脚手架的额外复杂性(与Windows窗体的互操作性不是无缝的)？
您的经理可以接受(或分散注意力)开发人员生产力的重要DROP四到六个月吗？
最后一个问题是由于我喜欢将其视为WPF的"FizzBin"性质,有十种不同的方式来实现任何任务,并且没有明显的理由偏向于另一种方法,并且很少有指导可以帮助你制作一个选择.您所做出的任何选择的缺点不仅会在项目的后期很明显,而且几乎可以保证您的项目中的每个开发人员采用不同的方法,从而导致严重的维护问题.当你试图学习框架时,最令人沮丧的是不断绊倒你的不一致.
您可以在我的博客上的条目中找到更多与WPF相关的信息:
http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx
| 归档时间： |
|
| 查看次数： |
1679 次 |
| 最近记录： |