从 Windows 窗体迁移到 WPF...值得吗？答案

【问题标题】：Migrating from Windows Forms to WPF... was it worth it?从 Windows 窗体迁移到 WPF...值得吗？
【发布时间】：2010-10-06 18:14:13
【问题描述】：

我还有一个用 Windows 窗体编写的桌面应用程序，大小适中（几十个主要窗体由数据库中的 46 个表支持）。我正在考虑用 WPF 重写 UI，但在我去那里之前，我很好奇是否有任何关于进行这种转换的战争故事。

我使用LLBLGen 来生成我的低级数据访问对象，并且我在其之上有一个业务逻辑层。尽管主表单使用缓存对象来最小化更常见的导航路线上的往返行程，但表单是数据绑定到业务逻辑对象的。 UI 从不直接与数据库对话：总是通过 UI -> 业务逻辑 -> 低级 -> 数据存储路径。

我经常使用的一个控件是 TreeView，它充当视觉指南和短程导航工具。该树已通过图标、突出显示颜色进行了大量自定义，这是我最担心移植的控件。

有没有什么故事可以说服我继续转换（或者相反，等到微软更接近于从 Windows 窗体下撤出地毯）？

编辑：有人在评论中问我有什么转变的动机。我对未来的校对有些担心：我有 500,000 行代码，这些代码最初是 ASP 和 VBScript。随着时间的推移，我们一直在将功能移植到 ASP.NET 和 C#，但仅在我们对代码进行更改时。好处是我们将成本降到最低，坏处是一半的代码仍然是 ASP 和 VBScript。我担心 Windows 窗体应用程序会出现类似情况。

今天我是否担心 Windows 窗体会消失？甚至还没有接近它……但该应用程序正在从 ASP 和 VBScript 转移到 ASP.NET 和 C#，已经有 9 年的历史，而且这十年可能不会被取代（相反，它会不断发展）。桌面应用程序同样是一个具有多年历史的长期项目。

【问题讨论】：

在未来相当长的一段时间内，微软可能不会弃用 WinForms。事实上，我敢说，在 Win32 API 被替换之前，它永远不会被弃用。
你想转换的原因是什么？
WPF versus Windows Forms的可能重复

标签： wpf winforms

【解决方案1】：

对我来说，WinForms 与 WPF 的决定是一个简单的决定 - 如果普通人要使用它，用户界面可以决定胜负。

这绝对是一个陡峭的学习曲线。但是我从来没有完成过一个漂亮的 WPF 应用程序并说“伙计，我应该使用 WinForms”。

我想说的是，尽可能地为您的客户努力让您的 UI 变得更好，所以如果是这样的话，那就是 WPF。

【讨论】：

在您的体验中，是什么让 WPF 用户界面优于 WinForms UI？即，作为 ROI 驱动程序，什么是值得指出的好地方？
更高质量的图形（一切渐变、透明度等）和情节提要。基本上考虑最小化一个窗口 - 如果它只是消失与“飞到任务栏”。动画有助于沟通功能。
嗯。我在保险领域：美元回报沟通功能。渐变、透明度和“飞窗”传达了太多浮华和空闲时间:)
@Godeke 不同意 - 一个好的 UI 可以传达一个做得好的软件产品。如果你有一个垂直/利基市场产品，你可以把它变成垃圾，人们会使用它，因为没有别的了。
我同意好的 UI 可以传达高质量的软件，但持有 Godeke 钱包的人却不这样做，他们才是最重要的。

【解决方案2】：

WPF 的学习曲线非常大。它很可能需要你重写比你想象的更多的东西来改变 UI。此外，许多使 WPF 更易于使用的功能尚未实现或包含在 WPF 中。 Unlike routeNpingme，我编写了漂亮的 WPF 应用程序，并说：“真是浪费时间，我应该使用 Windows 窗体并在 70% 的时间内完成”。

编辑： 此外，除非微软想出一种方法让 WPF 更容易学习，否则我认为它根本不会吸引大众。 WPF 可以做一些非常酷的事情，但是稍微努力让它易于理解而不是把东西扔到墙上就会有很长的路要走。看到微软放弃 WPF 以在不久的将来更容易使用，我一点也不感到惊讶。所以不要仅仅为了改变它而改变你的 Windows 窗体应用程序。

【讨论】：

您是否注意到学习曲线的特定方面（设计器工具、正确的数据绑定、性能......其他）？
XAML 和所有细微差别都是主要障碍。如果你搞砸了 XAML，那么工具支持在帮助发现问题方面非常薄弱。通常您只会收到一条短信，告诉您有错误，但没有说明错误可能出在哪里。

【解决方案3】：

移植是一个艰难的决定。因此，请提供一些想法来帮助您做出决定。

WinForms 在您按规则工作并保持原样绘制的情况下是可以的。但是，即使在某些控件上重新绘制边框也可能需要复杂而精确的工作和技能，正如您从树自定义中所知道的那样。在 WPF 中可以以非常优雅的方式完成相同的任务。

此外，WPF 中的数据绑定为我节省了大量时间。从长远来看，您最终会考虑在没有特殊情况编码的情况下无法在 WinForms 中远程实现的数据绑定场景。

我什至不考虑将 WinForms 用于新开发——没有任何理由需要定制成本。

【讨论】：

我们唯一的自定义绘图是使用 TreeView，所有这些都是通过位图、颜色和字体更改（例如删除线）来完成的。剩下的就是对库存控件的非常简单的数据绑定，尽管我确实有一些我想简化的“编辑器”对话框。

【解决方案4】：

WPF 很棒。它特别适合通过自定义扩展诸如 TreeView 之类的控件。您可以将字符串添加为 TreeControl 中的项。您还可以添加一个小面板，其中包含图像和一些不同字体和颜色的文本。或者你可以添加按钮，或者任何你喜欢的东西。它有一个完全通用的可组合性系统。 ListBox、ComboBox、Button 等也是如此。它们的所有内容或子项都可以像字符串一样简单，也可以像带有缩放按钮的多页文档查看器一样复杂（如果需要）。

但找出答案的唯一方法是尝试移植您的一种表格。从现有应用程序中打开 WPF 窗口应该不会太难。我通过制作托管在 C++ Win32 应用程序中的新 GUI 面板开始使用 WPF。最终很明显，WPF 是我们要走的路，所以我们把它换掉并制作了外壳 WPF，一些古老的对话框仍然由旧的 C++ 代码实现，我们懒得重写它们（可能正是将在 Visual Studio 2010 中发生）。

【讨论】：

我喜欢托管控件的想法：它提供了一种无需完全重写即可尝试 WPF 控件的轻松方式，并且可以避免编码更重的 UI 页面受到伤害。
也不要觉得你必须在 XAML 中做所有事情。关于拆分表示和模型有很多炒作，但对于许多应用程序来说，这不是必需的，甚至没有意义。此外，您还必须聘请一位熟练掌握 XAML 的设计师。如果您不打算这样做，请使用您最熟悉的语言。

【解决方案5】：

优点：

数据绑定非常简单（大多数时候）
外观和感觉的自定义非常简单

缺点：

非常陡峭的学习曲线
一些明显的错误或问题。类似于 .NET 1.0 Windows 窗体
很少或没有工具支持

在我看来，WPF 肯定会在某个时候取代 Windows 窗体。然而，现在工具是保持它的主要因素。我不同意 Dunk 的观点，即微软会为了别的东西放弃它。改变它是的，但我认为它会留下来。

您现在应该更改您的应用程序以使用 WPF 吗？不会。随意学习 WPF，但如果您的应用程序当前运行良好，那么 WPF 不会给您任何额外的东西。它只是让在 Windows 窗体中可以做的事情变得更加容易。

【讨论】：

听起来是个试验的好时机，但可能还不是完全投入的时候。

【解决方案6】：

我已经开始在我的 WinForms 应用程序中引入 WPF 元素，到目前为止已经取得了很大的成功。

应用程序的主要组件是一个网格控件，我还没有发现 WPF 的文本渲染足够清晰，无法呈现重要的文本数据表。

但该应用程序有几个附加面板，其中大部分是使用 WPF 实现的。因此，我将通过ElementHost 控件混合使用 WinForms 和 WPF。

我发现 WPF 的灵活性可以实现更具吸引力和可用性的 UI，我的用户似乎对此非常满意。就我而言，一次引入一个面板在政治上也更容易。

【讨论】：

【解决方案7】：

WPF 对我的主要价值在于绑定，而不是更酷的 UI。我见过的最糟糕的 WPF 是人们仅仅因为它更新而使用 WPF，并将所有工作都放在代码隐藏中，包括不使用绑定。你得到的是 WinForms 数据管理。因此，请确保在执行 WPF 时要使用美妙的绑定。

我会将 OP 的业务逻辑移植到业务层，以便于维护和转换。除非需要新的 Xaml 功能，否则我根本不会将 WinForms 移植到 Xaml，最好是在移植该功能之后。

【讨论】：