利用午休时间继续把过去写的一些代码翻出来说一说,文章可能写的比较简略,但是我会努力把核心意思表达清楚,具体代码可直接访问 Github 获取。
Github 地址:https://github.com/iccb1013/Sheng.Winform.Controls.Controller
这些代码是针对 WinForm 写的,但稍加改动即可应用于 WPF 开发中。
提到控制器,我们可能会首先想到流行的 MVC 开发中的控制器 Controller。对于 MVC 开发来说,我们把工程结构划分为 模型、视图、控制器。这是比较宏观的工程角度的划分,那么对于一些小范围的,更具体的编码问题,这样的模式是否能够借鉴呢?答案是肯定的。
在我们的客户端应用程序开发中,可能会涉及大量的控件操作的代码,如 TreeView,DataGridView,ListBox 等等,这些控件虽然都提供了基本的数据操作接口,但是这些接口的功能都非常的基础和简单,考虑如下操作:
- 在控件中使指定的数据处于选中状态;
- 在控件中删除符合条件的数据;
- 向控件中的指定位置添加数据,并判断数据的类型是否符合预期;
- 在控件中查找符合条件的数据;
- 获取控件中选中的数据,直接返回强类型结果;
- 移动指定的数据到另一个数据项目之前/之后;
- 展开树控件中符合条件的树节点;
这些操作有一个重要的共同点,都是针对“数据”进行操作,但是基本的的控件接口,没有这么多功能,既有的接口也多是以 object 作为参数来操作的,如果要实现这些功能,很多时候程序员需要写一些“业务代码”来完成,在业务代码中迭代数据源,写条件判断,做类型转换,最后调用控件的基本操作接口。
通常代码看起来如下图这样:
那么这些共通的功能,是否能够抽象出来呢?答案是肯定的,于是我们可以考虑继承这些控件,来添加我们想要的功能:
我们把这些共通的操作,实现在继承的控件中,然后在项目中使用自己实现的控件,这不失为一个办法,但是通过继承来实现这样的功能,有很大的缺陷:
- 必须在项目中所有使用控件的地方,使用继承而来的控件,对于全新开发的项目尚可考虑,但是对于中后期的项目,再去修改这些控件代价与风险过高;
- 有些项目本身使用了第三方控件,那么你针对原生控件的继承的实现就无法使用,必须针对第三方控件再做一次继承和实现;
- 有时我们会需要某些特定的操作,只在某些情况下使用,如果全部写在继承的控件中,代码可能会冗余和过大,如果在继承的基础上再继承一次,结构过于繁杂;
这里要引出一句话:对象的复合优于对象的继承。
我们使用复合不同的对象(控件和控制器)的方法,来解决这个问题:
我们可以为不同的控件,实现它们对应的“控制器”,然后在控制器中,实现我们的这些方法,这样做可以最大程度的获得灵活性与可控性,我们直接使用原生(或第三方控件)来开发项目,然后在代码中,为控件初始化一个控制器,接下来使用控制器来操作控件,对于上文提到的除了共通的操作外,还需要某些特定的操作的情况,可以实现为不同的控制器进行操作。
看一个控制器实现的代码示例,这是一个支持通过类型(Type)来呈现和操作数据的 DataGirdView 的控制器:
使用构造函数接收一个原生的 DataGridView 控件实例来包装它,及时是第三方控件,只要它是继承自 DataGridView 的,就可以直接使用。
接下来就可以直接使用控制器中的诸多方法,来操作控件,实现我们上文中提到的诸多功能。
代码的具体实现其实并不复杂,并且代码写于很多年前,有些细节的实现现在看来也并非最佳,只为抛砖引玉,轻拍。
具体的代码实现可以访问我的 Github 获取,包括:
- DataGridViewController
- TabControlController
- TreeViewController
- ListBoxController
你可以直接使用这些代码,也可以参考这些代码和本文所提出的思路,实现更多的控件控制器。
Q:279060597 @南京
http://sheng.city/post/github-winform-wpf-sheng-winform-controls-controller