这个问题是与同事进行午餐时间对话的结果......我读过像WPF和Winforms这样的问题......我个人认为长期 WPF是要走的路.问题/问题是在此期间要做什么.
是的,WPF当然有其优势; 不是建立在GDI/USER上的就是其中之一.但是在这个时间点(即2009年末;使用VS2008或甚至VS2005; Silverlight3最近发布并且尚未广泛采用/部署),WPF几乎看起来可能是一个"过度设计"的解决方案.虽然我确信它会随着时间的推移而改变,但它不会让今天的事情变得更容易,也不会使眼前的(比如<36个月)更加容易.
让我们面对现实,WinForms 非常简单易行; 特别是对于仍然"幸福地"使用MFC的许多同事而言.是的,可能很难做出光滑的动画,3D图形,渐变等; 但它是一个非常实用的解决方案,许多人(即C++/MFC开发人员)今天很容易理解.
随着那个漫长的介绍 - 有人想/累了/等等.关于使用WPF实现(大多数)WinForms的想法(即,WinForms 没有 GDI/USER)？我敢肯定Control.Handle,100%重新实施是不可能的.但看起来很多WinForms控件似乎可以使用WPF"引擎盖下"重新实现.或者这真的是边界线不可能吗？
通过"重新实现",我设想删除对System.Windows.Forms的程序集引用,用(比如)Microsoft.Wpf.WinForms替换它们,然后重建我的应用程序.之后,我希望修复一些(相对较少数量的)编译器和/或运行时错误(比如P/Invokes到Win32 API).
像这样的东西似乎是微软各种WinForms/WPF互操作策略(如WindowsFormsHost)的很好的补充.例如,开发人员可以以更加渐进的方式开始使用/学习WPF.
编辑:虽然各种"为什么？" 讨论很有意思,他们没有回答基本的技术问题:"是的,......这是怎样的......;或者不,......因为......".
老实说,我认为你可能实现一个层,允许你将大多数WinForms移植到WPF,但你真的不应该.让我用一个类比 - 从WinForms转移到WPF就像从命令式语言转向面向对象语言(或从OO转向纯函数).它真的很难,似乎没有什么工作正常,解决方案没有意义,一切似乎都过度设计,然后......你明白了.你有一个洞察力,灯泡继续,你看到一个全新的世界,任务更容易完成,更容易维护(比在WinForms中).
但首先你必须弄清楚它.在WPF中保持WinForms风格的编码非常容易,所以你必须强迫自己不要或者你永远不会采取下一步.强迫自己从一个干净的平板开始,学习如何应用MVVM,看看Prism,构建一些非常简单的应用程序,然后添加它们以探索如何管理WPF方式的复杂性.您可以在WPF中实现WinForms,但您所拥有的只是在WPF中编写WinForms的人.你基本上最终得到了(从Imperative - > OO天),使每个类都成为一个包含所有静态方法的单例.您可能正在"使用"WPF,但您(和/或您的同事)将永远不会超过该阶段.
根据我的情况,我建议您不要尝试切换到WPF,除非您正在与一个小团队一起编写新的应用程序.如果情况确实如此,那么小团队就可以成为变革的核心,因为一旦你的组织中的一个人"得到它",他们就会教他们附近的其他人,直到灯泡开始四处转动.这就是我们在现有组织中所做的,回顾过去6个月中每个人所取得的进步是惊人的.