Build your own CAB(Composite Application Block) Part #2 – The Humble Dialog Box

自己动手写CAB(Composite Application Block) #1 —— 前言

作者：Jeremy Miller 翻译：Yanwei

昨天本人提出了一个不负责任的观点。这个观点是，如果你要写一个可维护的，复杂的WinForms界面，并不需要Composite Application Block(CAB)。我觉得，开发人员如果掌握了CAB的底层设计模式，并且挑选一个不错的IoC/DI工具，就可以开发一个满足需求的设计。我甚至感觉，这个开发人员，如果对CAB功能很熟悉，就能够很容易地开发出一个性能更好的设计。为了证明我的这个观点，并且满足很多人对这个主题的好奇心，我将把DevTech上关于WinForms模式的演讲总结一下，写成一系列文章，来向大家展示，为了写出可维护的WinForm代码，而采用的一些设计思路。即使你坚持使用CAB(也没关系)，我希望，你能跟着我一起揭开CAB的神秘面纱。在分析实现中的一些模式后，能帮助你把CAB玩的更加得心应手。如果你觉得在某些方面，CAB比我的做法更好，请一定告诉我。

我最喜欢的作家之一是大仲马。他写过《三个火枪手》和《基督山伯爵》。《三个火枪手》是那个时代的肥皂剧，被写成很多章节连载在当时的杂志上。同样的，我也将把我的文章写成很多小章节。每一章节的长度就是我上下班做火车的时间内写出的长度。

关于文章中出现的术语——我是一个“跟屁虫”，所以我就用Martin Fowler关于企业设计模式丛书中的术语。

不就是UI么？

不就是UI么？最近这种言论不常见了，但我刚开始参加工作的时候，很多人都觉得，写UI代码很简单，且没有技术含量，真正的程序员是不应该关注的。我经常想起“小菜一碟”这个成语。这种态度不对，因为在很多系统中，UI代码比服务器端代码复杂的多。在如何设计UI代码上，多花时间好好琢磨一下，是绝对有必要的。下面我来好好论述一下：

写UI要花大量时间成本。不仅仅是指开发成本，根据我的经验，UI代码bug最多，因此维护成本最大。我们可以为UI代码尽可能多的写单元测试，来减少bug。黑TDD的人经常拿UI当例子，叫嚣有些代码就是不能测。他们错了，但是UI确实不好测。你需要多花点力气组织代码，让它们更容易测。

林子大了，什么样的用户都有，UI代码面临的是五花八门的输入数据。想要系统不崩溃，就一定得花点心思处理各种变态的输入数据。

界面频繁更改。我的经验再一次告诉我，比起后台逻辑，前端界面更容易变动。让UI能够拥抱变化，绝对是有意义的，只不过，需要好好设计。

UI代码大部分都是事件驱动的，而事件驱动的代码debug起来很恶心。所以让代码解耦，可测试，你就不用debug了，或者至少让debug变得简单一些。

设计模式之我见

我知道，很多人都对设计模式不屑一顾，认为设计模式是“繁文缛节”，不接地气。但我认为，在设计UI的时候，设计模式异常重要。在讨论设计的时候，设计模式给我们提供了通用的术语。这些模式凝聚了前人的智慧。这个系列文章中涉及到的模式，让我们在面对，怎样使UI代码职责分离的问题上，提供了很好的思路。我这么说，是因为...

UI代码中有很多不同的职责

一件近乎搞笑的事情是，DevTech上的每一个演讲者，包括我在内，至少有一个PPT页面赫然写着：单一职责(SRP)。再啰嗦一下，单一职责说的是任何一个类，“只能有一个理由去变化”。也就是说，你应该努力让你的每一个类只拥有一个内聚的职责，也就是说，只关心一件事情。我上面提到过，UI代码很容易变得很复杂。口说无凭，下面我们来列一下，一个最基本的界面，会包含哪些职责：

用户看到的静态界面

绑定事件，处理用户输入

根据业务逻辑，验证用户输入

不同用户，有不同的权限

不同用户，有不同的定制

界面的切换，以及相关信息的传递

与后台交互

这些都是多么重要的事情啊！如果这些代码我分而写之，那么问题就会被各个击破。我也非常想把这些代码分而测之。回到单一职责，如果我把这些职责都放在各自的代码中，就能更好的拥抱变化，易于维护。我们跪求的就是把这些职责分开的思路和策略。

当然，如今开发WinForms，最常见的分离职责的模式是...

View自治模式

你可能不会踱着步子，念念有词“我正在用‘View自治模式’写应用程序 ”，但一说你心里就明白。所谓View自治模式，指的是把界面的显示和界面的事件封装在一起。在WinForms开发中，View自治指的就是封装良好的Forms and UserControlls。当然这样的封装，对于只有几个UI界面的小应用非常合适。但是由于显示和行为耦合在了一起，应用越复杂，这种设计，在维护方面，就会越力不从心。当然在我看来，最大的问题，其实相比POCO类，这种自治View很难被单元测试。而且因为和WinForms内部实现机制耦合在一起，View自治的代码也会更加难读懂。当然你可以在内存中实例化WinForms对象，对这些对象进行单元测试，但写这样的测试困难重重，得不偿失。