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

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

I use LLBLGen http://en.wikipedia.org/wiki/LLBLGen生成低级数据访问对象，并且在其之上有一个业务逻辑层。尽管主表单使用缓存对象来最大程度地减少更常见导航路线上的往返行程，但表单仍通过数据绑定到业务逻辑对象。用户界面never直接与数据库对话：始终通过 UI -> 业务逻辑 -> 低级 -> 数据存储路径。

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

有没有一个故事可以说服我继续进行转换（或者相反，等到 Microsoft 更接近于从 Windows Forms 下撤出地毯）？

编辑：有人在评论中问我转换的动机是什么。我对未来的证明有些担心：我有 500,000 行代码，这些代码最初是 ASP 的，VBScript http://en.wikipedia.org/wiki/VBScript。随着时间的推移，我们一直在将功能移植到 ASP.NET 和 C#，但前提是我们对代码进行了更改。优点是我们将成本降至最低，缺点是一半的代码仍然是 ASP 和 VBScript。我担心 Windows 窗体应用程序会出现类似的情况。

我担心吗today关于 Windows 窗体的消失？甚至还没有接近......但该应用程序正在从 ASP 和 VBScript 转向 ASP.NET 和 C#，其背后有九年的历史，并且可能在这十年内不会被取代（相反，它只是会发展）。桌面应用程序同样是一个具有多年历史的长期项目。

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

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

我想说的是，只要有可能，就应该努力让你的 UI 为你的客户提供更好的服务，所以如果是这样的话，对 WPF 来说是的。