问当创建新的GUI时，WPF是Windows窗体的首选吗？

EN

WPF可以让你做出一些令人惊叹的事情，我喜欢它......但是当开发人员问我是否认为他们应该转向新技术时，我总是觉得有必要说下我的建议。

你的开发人员是否愿意（最好是EAGER）花时间学习如何有效地使用WPF？我从来没有想过要对MFC，Windows Forms，甚至是非托管DirectX这么说，但你可能不希望一个团队试图在正常开发过程中“拾取”WPF。运送产品的周期！

至少有一两个开发人员有一些设计敏感性，并且具有最终设计权限的人员对开发问题有正确的理解，因此你可以利用WPF功能来创建实际上更好的东西，而不是更“多彩” ，以无偿动画为特色？

你的目标客户群中有一部分是否在集成显卡芯片组上运行，这些芯片组可能不支持你正在计划的功能 - 或者它们是否仍在运行Windows 2000，这将消除它们作为客户？有些人会问，你的客户是否真的关心增强的视觉效果，但是，在90年代早期，我经历过内部公司“我们的商业客户不关心色彩和图片”的争论，我知道你的竞争对手提供的设计良好的解决方案会让他们关心，而真正的问题是这些条件是否正确，使你能够提供一些能够让他们在乎的东西。

该项目是否涉及理论上的发展，至少对于表示层来说，是为了避免尝试挂钩到不兼容的遗留脚手架（Interop与Win Forms不是无缝的）的额外复杂性？

你的经理能否接受（或分散注意力）开发人员生产力的显着下降时间为四到六个月？

这最后一个问题是由于我喜欢认为WPF的“FizzBin”特性，有十种不同的方式来执行任何任务，没有明显的理由更喜欢一种方法到另一种方法，并且没有什么指导可以帮助您制作选择。不仅您在项目中做出的任何选择的缺点都会变得很清楚，而且实际上保证让项目中的每位开发人员采用不同的方法，从而导致严重的维护头痛。当你尝试学习框架时，最令人沮丧的是不断出现的不一致性。

经过三个月试图在WPF上找到一个业务线（LOB）应用程序，我已经达到了考虑回到Windows Forms以供我的项目使用的点，并且在研究其他人的意见时，碰到了这个线程......

WPF在将GUI与业务逻辑分离方面解决的“问题”不是Windows窗体无法轻易解决的问题，只需从正确的架构和思维开始即可解决。即使是WPF的对象路径绑定功能，也可以使用一些非常简单的帮助程序类在Windows窗体中进行重现。WPF的数据模板功能非常好，但它们又是什么，在这些罕见的情况下，你无法在Windows窗体中模拟，当你完全不知道你将在任何给定的部分屏幕。

Windows Forms比赛在成熟度方面处于领先地位。另一方面，WPF的可用学习资源相对较少，可用的定制控件较少，并且没有解决许多初期问题。

在WPF与Windows Forms决策的高峰期，必须成为开发环境的成熟阶段。Windows Forms编辑器非常灵活，响应迅速且直观。关于错误的反馈可以立即得到，解决方案通常很明显，Windows窗体中的编译 - >调试 - >编辑周期非常快。

另一方面，WPF应用程序具有相对可怜的设计时间支持，并且设计视图全都准备好了，以便在第一次遇到错误时出现问题，通常需要在修复之后在设计师愿意启动之前修复项目再次。考虑到它根本无法工作的广泛环境，或者产生完全不直观的结果，可能不支持从工具箱中拖放组件。尽管WpfToolkit的承诺，仍然没有一个可用于WPF的DataGrid，可以产生任何形式的合理性能或设计时友好性。

调试WPF应用程序有点像旧的 ASP.NET调试范例... hit F5- > wait - > launch - > error - > stop - > fix - > hit F5- > wait - > launch - > error - > groan - >停止 - >修复 - >命中F5....你的程序运行的所有XAML都被锁定，并且跟踪XAML特定的问题往往是单调乏味的。

简而言之，底线是Windows窗体开发工具将让你在WPF应用程序的一小部分时间内暴露前端...... 特别是如果你要创建主细节网格或电子表格像大多数LOB所具有的接口一样。使用Windows Forms，你已经为你完成了90％的工作。

我是WPF架构的忠实粉丝。我只是希望设计时工具集不像是一个前置alpha调试版本。