14

有没有一种实用的方法可以让我们慢慢地将 WinForms 应用程序发展为 WPF，而不会为我们自己制造奇怪的互操作场景的支持噩梦？

背景资料：

我们有一个大型战舰灰色 WinForms 应用程序，被大约 60-75 个用户的内部组大量使用。我们开始遇到一些地方，我们可以从 WPF 中的应用程序中看到一些好处，但这还不足以证明一个大型项目完全重写它是合理的。应用程序中的所有屏幕都是独立的 WinForms 用户控件，而 WinForms 应用程序只是一个处理菜单、打开/关闭表单、提供一些共享帮助方法等的外壳......

到目前为止，我们的最佳想法是将 shell 应用程序转换为 WPF，然后在其中托管 WinForms 用户控件。我们认为，随着时间的推移，我们可以转换用户控件，将这些更改与具有足够业务价值以支持额外工作的计划联系起来。我担心互操作的工作情况以及它将如何影响性能。我还担心我们如何过渡到应用程序的新外观。让 shell 应用程序看起来很时髦，然后在其中托管旧的战舰灰色用户控件似乎很奇怪，在 WPF 中创建 shell 应用程序并让它看起来就像在 WinForms 中一样似乎也很奇怪。

如果 Caliburn、Prism 或其他类似框架中的一个可以简化过渡，我们也愿意探索这些选项。

4

2 回答 2

11

我们处于类似的情况并选择了以下路径：一开始我们开始在应用程序外壳中托管几个 WPF 窗口（仍然是 WinForms）。当然有一些明显的差异，但我们故意通过淡化新窗口来减少差异。我们认为，当我们转换剩余的窗口/控件时，将更容易“升级”到更生动的体验，因为 UI 将完全是 WPF，我们可以让图形设计师基于 XAML 发挥他们的魔力。

我们现在已经达到了大多数窗口都是 WPF 的程度。我们已经开始将 WinForms shell 应用程序转换为基于 WPF 的 shell 应用程序来托管剩余的 WinForms。我们仍然有一些暗淡的颜色，但用户已经开始注意到差异，虽然它很小，但我们的用户仍然喜欢渐进的积极变化。不会太久，我们将淘汰最后一个 WinForm。这将是我们让我们的图形设计师摆脱束缚的关键！

至于性能：我当然不能做出一般性陈述，因为它在很大程度上取决于您的特定控件/窗口。在我们的产品（数百个窗口）中，我们没有发现任何与 WPF 和 WinForms 混合相关的重大性能问题。

我们没有研究任何框架，所以恐怕我无法评论这些。

于 2010-08-11T11:45:57.483 回答
4

很好的问题，目前 WPF 中的大部分工作都涉及将旧的 WinForms 应用程序转换为 WPF。根据我的经验，最好的情况是根据旧的应用程序/需求从头开始构建应用程序。幸运的是，我参与了一个项目，我们从头开始重新编写了应用程序，我相信与混合两者相比，它花费的时间/投资更少。

我个人认为，如果我们尝试将两者混合起来会造成混乱。另一点是，很难有效地设计混合应用程序。

在我当前的项目（这是一个从过去 10 年开始运行的大型项目）中，我们正在逐个模块转换应用程序模块。对我们来说幸运的是，我们的应用程序由各种较小的应用程序组成，因此将它们一一转换更容易。在您的情况下，我会说您确定可以完全转换为 WPF 的区域并开始在 WPF 中构建它们，如此处所建议的 -

Windows 窗体 - WPF 互操作性常见问题解答：http: //windowsclient.net/learn/integration.aspx

我还建议使用一些工具将 Windows 窗体转换为 XAML(WPF)；这肯定会帮助您节省一些时间。

Windows 窗体到 WPF 转换器： http ://wf2wpf.codeplex.com/

Windows 窗体到 XAML 转换器：http: //www.ingeniumsoft.com/Products/WinForm2XAML/tabid/63/language/en-US/Default.aspx

Windows 窗体到 Windows Presentation Foundation 转换器： http ://www.spiderwan.com/spiderwan/ConvertWinFormToWPF/WinFormToWPF.aspx

于 2010-08-11T11:52:08.997 回答