为什么要MVC

    最近在公司写了一大堆复杂的界面，终于体会到了前辈们那种上刀山下火海的感觉了。做完了之后回头想想，MVC还是有道理的。

    什么是MVC？其实可以简单的理解为一个有UI的程序可以划分为三个部分：数据层、逻辑层和应用层。当然这些名字是我乱起的。数据层顾名思义就是用来读写数据的地方，譬如说一个电话本的文件。逻辑层就是用户在界面上的操作的抽象，譬如说要通过名字来查找消息啦，给一个关键字求得筛选后的电话信息列表啦。应用层指的就是那一堆控件了。MVC三个字母分别指的是Model、View和Controller，也就是模型、视图和控制器了，分别对应于数据层、应用层和逻辑层。

    以前在看MVC的时候总是被一些教条主义的东西迷惑，说什么在MVC里面，MV解耦，所以M可被替换，V也可被替换。这个时候往往会感到迷惑。为什么模型，或者说数据层要被替换？为什么视图，或者说界面要被替换？其实这在一个不是复杂到神级级别的程序里面是不会发生的。但是MVC并不是为了让你能够实现模型被替换或者试图被替换而产生出来的，我觉得这个模式（其实这不是设计模式的其中一项，真的）更加重要的特点是可以让你的程序写起单元测试来更加容易。

    还是电话本，现在有一个要求，说在输入人的名字之后，只要系统检查出你超过0.5秒没有持续输入，那么底下的列表就会自动根据你上面的输入进行筛选。其实这有点像Outlook。这要怎么写单元测试？我们知道虽然正规的测试会有一大堆用来自动完成界面操作的工具啊，或者类库，但是作为单元测试来讲我们并不需要去做这种事情。因为单元测试是程序员写的，凡是程序员写的东西当然是需要尽快得到结果的。一般的开发方法是写一点代码，写一点测试，跑，有bug改没有bug继续。我们在开发程序的时候会不断地、频繁地跑单元测试，来看看我们的东西是不是有问题，或者在重构的时候我们对于我们的代码正确的信心会大一点。

    那界面怎么办呢？难道我们真的要去引入一个库来搞界面的自动测试吗？当然想要也可以，不过这毕竟太复杂，而且这一类的工具的稳定性其实都不是特别好，被误导的几率倒是大增。这仅仅是对于程序员来讲的，当然搞测试的那些人自有他们的办法。那既然我们不做界面的自动测试那怎么知道文本框被输入之后究竟筛选出来的数据对还是不对呢？

    答案：MVC。

    为什么View，也就是试图，也就是界面，可以被替换是一件很重要的事情？想一想，如果控件可以被换成单元测试的一段代码，那岂不是很爽么？举个例子，我们要告知用户说，我们的事情已经做了一半了，这个时候我们可能会去设置进度条的位置。但是“告诉用户说我们的事情已经做了一半”跟“设置进度条的位置”其实是完全无关的两件事情。因此我们的Controller要负责通知View说事情做了一半了，然后View就可以去设置进度条的位置了。现在我们把View换成单元测试的一段代码，这个时候就变成Controller通知测试程序说事情已经做到一半了，然后测试程序就会去检查说现在是不是应该做到了一半，如果应该，显然这个用例就通过了。

    那Model呢？Model可以简单的理解为数据源，其实当然不只是那么简单，不过这样理解会让我们更容易接受一点。数据源是什么，当你写单元测试的时候，去连接一个数据库来获得数据源，然后就操作Controller，这个时候你如果不亲自去读一下数据库，你怎么知道Controller给你的东西究竟是对的还是错的？显然Model我们也可以换掉，测试程序伪造数据成为一个Model，然后插入Controller，事情就解决了。数据是我们自己给的，那Controller应该提供什么我们也能知道了。

    于是，使用了MVC之后，单元测试想换Model就换Model，想换View就换View，测试什么就非常容易了。至于说用户停止输入0.5秒之后是不是会真的去进行数据的筛选，这个我们手工测试就好了，而且那些搞测试的人也会帮我们检查的。

    好吧，说到这里有人可能会问为什么我没有给出一个Demo？这东西太虚，实践实践自己体会一下就行了，而且MVC变形那么多，有Model-View-Presenter，还有最近兴起的Model-View-ViewModel等等，其实现都跟传说中的那个类似桥接模式的东西差别甚远。这个自己去看一看就好了。