利用午休时间继续把过去写的一些代码翻出来说一说，文章可能写的比较简略，但是我会努力把核心意思表达清楚，具体代码可直接访问 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