我还有一个用Windows Forms编写的桌面应用程序,它是一个中等大小(由数据库中的46个表支持的几十个主要表单).我正在考虑重写WPF中的用户界面,但在我去那里之前我很好奇是否有关于进行这种转换的战争故事.
我使用LLBLGen生成我的低级数据访问对象,我有一个业务逻辑层.表单是数据绑定到业务逻辑对象,尽管主表单使用缓存对象来最小化更常见的导航路径上的往返.UI 永远不会直接与数据库对话:始终通过UI - >业务逻辑 - >低级别 - >数据存储路径.
我大量使用的一个控件是TreeView,它充当视觉指南和短程导航工具.树已经大量定制图标,突出显示颜色,这是我最担心的移植控件.
是否有一个故事可能说服我继续进行转换(或者相反,等到微软接近从Windows窗体中拉出地毯)?
编辑:我在评论中被问到我有什么转换动机.我对未来的打样有些担心:我有500,000行代码,最初是ASP和VBScript.我们已经将功能随着时间推移到ASP.NET和C#,但仅在我们对代码进行更改时.好处是我们保持成本最小化,缺点是代码仍然是ASP和VBScript的一半.我担心Windows Forms应用程序出现类似的情况.
我今天担心Windows Forms会消失吗?甚至没有接近它...但是应用程序正在从ASP和VBScript转移到ASP.NET和C#,已经有九年的历史了,并且可能在这十年内不会被替换(相反,它将会发展).桌面应用程序同样是一个具有多年历史的长期项目.
对我来说,WinForms与WPF的决定很简单 - 如果普通人会使用它,用户界面可以区分赢家和输家.
这绝对是一个陡峭的学习曲线.但我从来没有完成一个漂亮的WPF应用程序并说"伙计,我应该使用WinForms".
我会说,尽可能为您的客户投入更多努力使您的用户界面变得更好,如果是这样的话,那么WPF也是如此.
WPF有一个非常大的学习曲线.它很可能要求你重新编写比你想象的更多的UI.此外,许多使WPF更好用的功能尚未实现或包含在WPF中.与routeNpingme不同,我编写了漂亮的WPF应用程序,并说:"多么浪费时间,我应该使用Windows Forms并在70%的时间内完成".
编辑: 此外,除非微软想出一种让WPF更容易学习的方法,否则我认为它根本不会引起群众的关注.WPF可以做一些非常酷的事情,但是一点点努力使它易于理解而不是把东西扔到墙上会有很长的路要走.毫不犹豫地看到微软放弃WPF以便在不久的将来更容易使用.因此,不要仅仅为了更改它而更改Windows窗体应用程序.
优点:
缺点:
在我看来,WPF肯定会在某些时候取代Windows Forms.但是,现在工具是保持它的主要因素.我不同意Dunk的说法,微软会把它放弃别的东西.改变它是的,但我认为这是留下来的.
您是否应该立即更改应用程序以使用WPF?没有.随意学习WPF,但如果您的应用程序当前正常工作,那么WPF将不会给您任何额外的帮助.它只是使Windows Forms中的可能性更容易.
WPF 很棒。它特别适合通过自定义扩展 TreeView 等控件。您可以将字符串添加为 TreeControl 中的项目。您还可以添加一个小面板,其中包含图像和一些不同字体和颜色的文本。或者您可以添加按钮或任何您喜欢的内容。它有一个完全通用的可组合性系统。ListBox、ComboBox、Button 等也是如此。它们的所有内容或子项可以像字符串一样简单,也可以像带有缩放按钮的多页文档查看器一样复杂(如果您愿意)。
但找出答案的唯一方法是尝试移植您的其中一个表单。从现有应用程序中打开 WPF 窗口应该不会太难。我通过制作托管在 C++ Win32 应用程序中的新 GUI 面板来开始使用 WPF。最终,很明显 WPF 是正确的选择,因此我们将其转变并制作了 WPF 外壳,其中一些古老的对话框仍然由旧的 C++ 代码实现,我们懒得重写它们(可能正是这样)将在 Visual Studio 2010 中发生)。