.net - 使用 WPF 实现 WinForms？

Question

这个问题是在午餐时间与同事交谈的结果...我读过类似 WPF vs. Winforms 的问题。 ...我个人认为 长期 WPF是要走的路。问题/问题是在此期间要做什么。

是的，WPF 肯定有它的优势；不是建立在 GDI/USER 上就是其中之一。但是在这个时间点(即 2009 年末；使用 VS2008 甚至 VS2005；Silverlight3 最近发布但尚未广泛采用/部署)，WPF 几乎看起来像是一个“过度设计”的解决方案。虽然我确信这会随着时间的推移而改变，但它不会让今天的事情变得更容易，也不会让近期(比如 <36 个月)的 future 变得更容易。

让我们面对现实吧，WinForms 非常简单易行；特别是对于许多仍然“快乐”使用 MFC 的同事。是的，可能很难制作流畅的动画、3D 图形、渐变等；但它是一个非常实用的解决方案，今天很多人(即 C++/MFC 开发人员)很容易理解。

有了这个冗长的介绍——有没有人想过/累了/等等。关于使用 WPF(即 WinForms sans GDI/USER)实现(大部分)WinForms 的想法？我确定给定的东西像 Control.Handle , 100% 重新实现是不可能的。但似乎可以在“幕后”使用 WPF 重新实现许多 WinForms 控件。或者这真的是不可能的边界线吗？

通过“重新实现”，我设想删除对 的程序集引用。 System.Windows.Forms 将它们替换为(例如) Microsoft.Wpf.WinForms 然后重建我的应用程序。在那之后，我希望修复一些(相对较少的)编译器和/或运行时错误(比如 P/Invokes 到 Win32 API)。

像这样的东西似乎是对微软各种 WinForms/WPF 互操作策略的一个很好的补充，例如 WindowsFormsHost .例如，开发人员可以开始以更加增量的方式使用/学习 WPF。

编辑:而各种“为什么？”讨论很有趣，他们没有回答基本的技术问题:“是的。，..这里是如何......；或者不，......因为......”。

Answer 1

老实说，我认为您可以实现一个层来允许您将大部分 WinForms 移植到 WPF，但您确实不应该这样做。让我打个比方——从 WinForms 迁移到 WPF 就像从命令式语言迁移到面向对象的语言(或从 OO 到纯函数式)。这真的很难，似乎没有什么是正确的，解决方案没有意义，一切似乎都过度设计，然后……你明白了。您顿悟了，灯泡亮了，您会看到一个全新的世界，在这个世界中，任务更容易完成，也更容易维护(比在 WinForms 中)。

但首先你必须理解它。在 WPF 中保持 WinForms 风格的编码真的很容易，所以你必须强制自己不要这样做，否则你永远不会采取下一步行动。强制自己从头开始，学习如何应用 MVVM，看看 Prism，构建一些非常简单的应用程序，然后添加到它们中以探索如何以 WPF 方式管理复杂性。您可能会在 WPF 中实现 WinForms，但您所拥有的只是人们在 WPF 中编码 WinForms。您基本上最终相当于(从命令式 -> OO 时代)使每个类成为具有所有静态方法的单例。您可能正在“使用”WPF，但您(和/或您的同事)永远不会超过那个阶段。

根据我从您的情况中收集到的信息，我建议您 不是 除非您正在与一个小团队一起编写新的应用程序，否则请尝试切换到 WPF。如果情况确实如此，那么小团队就可以成为变革的核心，因为一旦你组织中的一个人“明白了”，他们就会教身边的其他人，直到灯泡开始在整个地方都亮起来。这就是我们在我目前的组织中所做的事情，回顾过去 6 个月中每个人取得的进步是惊人的。