我最近开始研究Win Forms应用程序,需要进行一些改进和重组。有可能在未来完成应用程序的WPF版本,我正在考虑将Win Forms应用程序重组为MVVM模式。目的是,在开发WPF的时候,我只需要专注于创建WPF视图并重用以前版本的代码。
我查看了一些使用MVVP模式开发Win表单应用程序的帖子,并且似乎可以使用该模式开发Win Forms应用程序。
我想知道这种方法是否可取,如果将现有的Win Forms应用程序重构为MVVM模式,可以在开发WPF版本时减轻工作量。
答案 0 :(得分:4)
这在我看来并不是一个好主意。因为MVF在WPF中如此优秀的原因非常重要,因为WPF绑定的基础设施。 WinForms没有这样的能力,绑定支持更低。这就是WinForms使用MVP模式的原因,其中Presenter负责向视图提供数据。 您可以尝试编写纯MVVM模型,但是您必须在视图中编写相当多的丑陋代码才能绑定到模型并更新它们。 我建议坚持使用MVP,因为这对WinForms来说非常好,它可以创建结构良好的组件,然后很容易在WPF和MVVM中重新创建相同的功能。
答案 1 :(得分:3)
与其他受访者一样,这里的问题是表示层,WinForms不像WPF那样容易处理。
据说,根据我的经验,许多传统的WinForm应用程序在表单代码中都有很多业务和数据层逻辑。
我认为没有理由不确保将代码分离到不同的数据层,业务逻辑和GUI中,以便为可能迁移到WPF做好准备。
答案 2 :(得分:2)
几个月前,我写了一个类似MVVM的小型winforms应用程序,只是为了好玩。我用自己的绑定...... 绑定代码放在代码隐藏中,看起来像:
this.Bind(src: x => x.ViewModel.SearchCriteria, dst: x => x.txtSearchCriteria.Text, mode: BindingMode.TwoWay);
顺便说一下,我还没有完成这个应用程序,但尝试尝试是很有趣的。)
总结:
1)有可能吗? - 是的,我已经尝试过这样做了,而且很有效
2)难以实施吗? - 不,不是很难
3)我建议在实际项目中尝试这个吗? - 不,使用MVP确实更好。
答案 3 :(得分:2)
正如弗拉基米尔所说,你可能可以重新设计你的Winforms项目以使用MVVM模式。但问题是:它值得吗? 你必须彻底重新发明轮子,并在支持WPF类绑定的类中包装Winform控件 想象一下,您开发了一个WPF应用程序并将所有业务放在代码隐藏中。它是可行的,但它不是正确的IMO,它肯定是丑陋的。
我将我的数据访问层分开,以便能够在未来可能的WPF项目中使用它。但我会尝试在应用程序中记录业务而不是迁移到MVVM,以便更容易从头开始构建WPF应用程序。