WinForms到WPF - 我们如何从这里到达？ [英] WinForms to WPF - How do we get there from here?
问题描述
有没有一个实用的方式，我们慢慢演变一个WinForms应用程序到WPF，而不会为我们自己创建一个支持噩梦与奇怪的互操作场景？
背景信息：
我们有一个大型战舰灰色WinForms应用程序，约60-75个用户。我们开始跑到一些地方，我们可以看到从WPF中获得应用程序的一些好处，但它还不足以证明一个大型项目完全重写它。应用程序中的所有屏幕都是自包含的WinForms用户控件，WinForms应用程序只是一个壳，处理菜单，打开/关闭窗体，提供一些共享助手方法等...
到目前为止，我们最好的想法是将shell应用程序转换为WPF，然后在其中托管WinForms用户控件。我们认为我们可以随时间转换用户控制，将这些更改与具有足够业务价值的计划相结合，以支持额外的工作。我关心interop如何工作以及它将如何影响性能。我也很关心我们如何转换到一个新的应用程序的外观。看起来奇怪的是，shell应用程序看起来很漂亮，然后有老战舰灰色用户控件托管在它里面，它也似乎奇怪，创建WPF中的shell应用程序，并使它看起来像它在WinForms。
如果Caliburn，Prism或其他类似框架中的一个可以缓和过渡，我们也可以开始探索这些选项。
我们在类似的情况下选择了以下路径：开始时，我们开始在应用程序shell（仍然是WinForms）中托管一些WPF窗口。当然有一些明显的区别，但我们通过调低新的窗口故意减少差异。我们认为，当我们转换剩余的窗口/控件，它将更容易升级更生动的体验，因为UI将完全是WPF，我们可以涉及一个图形设计器来工作他们的魔法基于XAML。 / p>
我们现在已经达到了大多数窗口都是WPF的点。我们已经开始将WinForms shell应用程序转换为托管其余WinForms的基于WPF的shell应用程序的过程。我们还有一些颜色，但用户已经开始注意到差别，虽然它很小，我们的用户仍然喜欢增量的积极变化。不要太长，我们将退休最后的WinForm。这将是我们让我们的图形设计师脱离皮带的时候！
至于性能：我绝对不能做一般性的声明，因为它在很大程度上取决于您的特定控件/视窗。在我们的产品（几百个窗口）中，我们没有发现任何与WPF和WinForms组合相关的性能问题。
我们没有看到任何框架，所以恐怕我不能评论这些。
Is there a practical way for us to slowly evolve a WinForms application to WPF without creating a support nightmare for ourselves with strange interop scenarios?
Background info:
We have a large battleship gray WinForms application that is heavily used by an internal group of about 60-75 users. We're starting to run into places where we could see some benefit from having the app in WPF, but it's not enough to justify a large project to completely re-write it. All of the screens in the app are self-contained WinForms user controls and the WinForms app is just a shell that handles menuing, opening/closing forms, provides some shared helper methods, etc...
Thus far, the best idea we've had is to convert the shell application to WPF and then host the WinForms user controls inside it. We thought that we could then convert the user controls over time, tieing those changes to initiatives that have enough business value to support the additional work. I'm concerned about how well the interop works and how it will impact performance. I'm also concerned about how we transition to a new look for the app. It would seem odd to make the shell app look snazzy and then have old battleship gray user controls hosted inside it and it also seems odd to create the shell app in WPF and make it look just like it did in WinForms.
If one of the Caliburn, Prism, or another similar framework would ease the transition, we'd be open to exploring those options as well.
We were in a similar situation and chose the following path: At the beginning we started to host a few WPF windows in the application shell (still WinForms). Of course there was some visible difference but we reduced the difference deliberately by toning down the new windows. We figured that by the time we would convert the remaining windows/controls it will be easier to "upgrade" to a more vivid experience since the UI will be entirely WPF and we can involve a graphical designer to work their magic based on XAML.
We have now reached the point where the majority of the windows are WPF. We have started the process of converting the WinForms shell app into a WPF based shell application hosting the remaining WinForms. We sill have sort of dull colors but users have started to notice the difference and although it is small our users still like the incremental positive change. Not too long and we will retire the last WinForm. That will be the point when we let our graphical designers off the leash!
As to performance: I can certainly not make a general statement as it heavily depends on your particular controls/windows. In our product (several hundred windows) we haven't found any significant performance issue related to the mix of WPF and WinForms.
We didn't look into any of the frameworks, so I'm afraid I cannot comment on those.
这篇关于WinForms到WPF - 我们如何从这里到达？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
