我没有开发太多桌面/ Windows窗体应用程序,但我发现使用MVC(模型视图控制器)模式进行Windows窗体.NET开发可能会有一些好处.
有没有人在Windows窗体中实现MVC？如果是这样,你对设计有任何提示吗？
我过去所做的就是使用类似的模型 - 视图 - 演示者.
[注意:本文过去在网上提供.要立即查看,您需要下载CHM,然后查看文件属性并单击"取消阻止".然后你可以打开CHM并找到文章.万分感谢,微软! 叹气 ]
表单是视图,我有一个IView接口.所有处理都在演示者中进行,演示者只是一个类.表单创建一个新的演示者,并将自己作为演示者的IView传递.这种测试方式可以传入假的IView,然后从演示者发送命令并检测结果.
如果我使用一个成熟的模型 - 视图 - 控制器,我想我会这样做:
表格是视图.它向模型发送命令,引发控制器可以订阅的事件,并从模型中订阅事件.
该控制器是预订视图的事件和命令发送到视图和模型中的类.
该模型引发视图订阅的事件.
这符合经典的MVC图.最大的缺点是,对于事件,很难分辨谁订阅了什么.MVP模式使用方法而不是事件(至少我实现它的方式).当表单/视图引发一个事件(例如someButton.Click)时,表单只是在演示者上调用一个方法来为它运行逻辑.视图和模型根本没有任何直接连接; 他们都必须经过主持人.
好吧,实际上Windows Forms实现了MVC的"自由风格"版本,就像有些电影对一些经典书籍实现了一些蹩脚的"自由风格"解释(罗密欧与朱丽叶的想法).
我不是说Windows Forms的实现很糟糕,它只是......不同.
如果您使用Windows窗体和适当的OOP技术,并且可能使用像EntitySpaces这样的ORM来进行数据库访问,那么您可以这样说:
ORM/OOP基础架构是Model
表格是观点
事件处理程序是Controller
尽管同一个对象所代表的View和Controller都使代码分离代码变得更加困难(在从Microsoft.Windows.Forms.Form派生的类中插入"GTK +视图"并不容易).
如果你足够小心,你能做什么.通过仅在事件处理程序中编写GUI相关内容以及在单独的类中编写所有其他业务逻辑,使表单代码与控制器/模型代码完全分离.在这种情况下,如果您想使用GTK +编写另一个View层,您只需要重写GUI代码.
Windows Forms并非专为使用MVC而设计.你有两个选择.
首先,您可以推出自己的MVC实现.
其次,您可以使用为Windows Forms设计的MVC框架.
第一个是开始做起来很简单,但是你得到的越多,它就越复杂.我建议寻找一个好的,预先存在且经过良好测试的MVC框架,旨在与Windows Forms一起使用.我相信这篇博文是一个不错的起点.
对于任何人开始,我建议跳过Windows窗体并针对WPF进行开发,如果你有选择的话.这是一个更好的创建UI的框架.正在为WPF开发许多MVC框架,包括这个和那个.
京公网安备 11010802040832号 | 京ICP备19059560号-6 