我还有一个桌面应用程序是用
Windows Forms编写的,它是一个中等大小(数十个主要表单,由数据库中的46个表格支持).我正在考虑在WPF中重写UI,但在我去之前,如果有这样一个转换的战争故事,我很好奇.
我使用LLBLGen生成我的低级数据访问对象,我有一个以上的业务逻辑层.这些表单是数据绑定到业务逻辑对象,尽管主窗体使用缓存对象来最小化更常见的导航路线上的往返行程. UI不会直接与数据库说话：总是通过UI – >业务逻辑 – >低级 – >数据存储路径.
我使用的一个控件是TreeView,它作为视觉指南和短程导航工具.树已经大量定制的图标,突出显示颜色,这是控制我最担心的移植.
有没有一个故事可能会说服我去转换(或者相反,等到微软更接近从Windows窗体中拉出地毯)？
编辑：我被问到一个评论是什么动机的转换我有.我对未来的打样有一些担忧：我原来是ASP和VBScript的代码有50万行.随着时间的推移,我们已经将功能移植到ASP.NET和C#,但是只有当我们对代码进行更改时.上行是我们保持成本最小化,缺点是一半的代码仍然是ASP和VBScript.我担心Windows窗体应用程序出现的类似情况.
今天我担心Windows窗体会消失吗？甚至没有接近…但应用程序正在从ASP和VBScript转移到ASP.NET和C#,具有九年的历史背后,可能不会被替代这个十年(相反,它将会演变).桌面应用程序同样是具有多年历史的长期项目.
WPF很棒特别适用于通过自定义扩展诸如TreeView之类的控件.您可以在TreeControl中添加一个字符串作为项目.您还可以添加一个包含图像的小面板和一些各种字体和颜色的文本.或者您可以添加按钮或任何您喜欢的按钮.它具有完全一般的可组合性系统. ListBox,ComboBox,Button等都是一样的.它们的内容或子项可以像一个字符串一样简单,或者像使用缩放按钮的多页文档查看器一样复杂(如果需要的话).
但唯一的办法就是尝试移植你的一个表单.在现有的应用程序中打开WPF窗口不是太难了.通过在C Win32应用程序中托管的新GUI面板,我开始使用WPF.最终,显而易见的是,WPF是我们切换的方式,并使外壳WPF,一些古老的对话框仍然由旧的C代码实现,我们无法重新编写它们(可能是什么将会发生在Visual Studio 2010).
