程序界面设计模式慨述

现在开发应用程序经常使用一些所见即所得的开发环境，使得用户界面的制作非常方便。然而，用户界面是最容易发生需求变更的部分，用户界面发生变化，经常对业务模块产生影响。并且，用户界面是不利于自动测试的。一旦某些代码依赖用户界面，这样的代码就很难在

现在开发应用程序经常使用一些所见即所得的开发环境，使得用户界面的制作非常方便。然而，用户界面是最容易发生需求变更的部分，用户界面发生变化，经常对业务模块产生影响。并且，用户界面是不利于自动测试的。一旦某些代码依赖用户界面，这样的代码就很难在别的模块中调用了，因此业务逻辑不能在界面层次中进行，否则会造成不能复用，不能复用自然会增加复制粘贴的代码，造成错误的扩散，放大需求变更的影响。在程序设计中，应该尽量做到用户界面和底层的业务模型分离。

用户界面和业务模块的互动方式，在程序设计中经常采用MVC模式。MVC模式并不是一个特别的模式，而是一些特定模式的组合。基本上包括三个对象：业务模块（Model）、用户界面（View）和控制器（Controller），关系如下：

图中实线表示高耦合的依赖关系，虚线表示低耦合的消息关系。业务模块是不依赖用户界面的，这样就隔离了用户界面的变更对业务程序的影响。用户界面负责收集用户的输入，显示用户需要的数据；控制器负责将用户的请求调用到实际的业务程序，也将业务程序处理的结果回送给用户界面；业务程序具体处理业务操作。同时业务模块可能主动发送消息到用户界面，通知界面显示数据。

在具体的环境下，这些因素可能发生一些变化。比如，在web开发中，由于web应用程序的性质，用户界面是在浏览器上运行的，而界面的控制和业务模块在浏览器上运行，所以在web应用中通常采用这种典型的MVC模式。并且在Web应用中，不存在服务器主动向客户端“推”数据，因此从Model到View之间的虚线也是不存在的。在windows窗体程序中，控制器和界面经常是合并在一起的，比如MFC框架中使用的Document－View模式，其中的Document对应MVC中的Model，负责保存业务数据，处理业务逻辑，View相当于MVC中的View＋Controller，负责用户界面的显示、用户输入的收集和画面的跳转控制。

好的设计和坏的设计有时候需要写的代码是一样多的，但是这些代码放的位置不一样。MVC中最重要的一点就是清楚Controller应该处于什么样的地位，应该完成什么样的功能。下面用一个web应用程序的例子来说明一下。

Jsp编程有一些MVC的框架，比如Struts，Struts控制器的工作如下：首先是一个请求分派机制，负责监听请求和分配请求，然后是一个Command模式的实现，负责处理请求。首先收到服务器收到客户端的http请求，交给控制器分析其中的地址，在一个配置文件中寻找对应的处理者（一个Action的子类），建立这个类的实例，随后执行其execute方法，Action类中调用业务模块进行实际业务的处理（在处理之前进行必要的准备，比如分析请求的参数，将其转化为业务模型了解的对象），得到处理结果，根据处理的结果决定需要显示的View。这个需要显示的View在Struts框架中也是在文件中配置的。

这是一种集中式的控制器，应用程序使用一个统一的Controller。不仅使业务和界面分离开，并且界面的流程完全由同一个对象来控制。最重要的是，使得功能的修改和追加变得比较方便，控制器成为业务模块的缓冲，减轻了需求变化对业务模块的影响。

很多windows窗体程序也采用这样的控制器。有一个开放源码的.Net开发工具，叫做SharpDev，本身也是用c#开发的，采用的就是这样的集中控制方式。SharpDev是用add-in的方式进行增量开发的，程序中的功能，如打开文件、保存文件、运行某个向导等功能都是一个个独立的add-in，使用了Command模式。程序运行过程大致如下：应用程序初始化的时候，读取配置文件中所有名称为*.add-in的文件，得到程序中所有的add-in，可以把这些add-in看作一个ICommand接口的实现。根据配置文件建立这些ICommand的实例，绑定在对应的菜单项和工具栏按钮上。当用户点击这些菜单项和工具栏按钮的时候，由一个任务分派的对象将请求定位到一个Command上，执行其Run方法。Command执行的时候可能要调用业务程序，业务程序是通过一系列的Service对外提供功能的，不直接向外界暴露。Controller就是负责定向用户操作到具体Command的分派器。

窗体应用程序还有一个特点：有时候业务改变的时候，需要用户界面作出相应的变化。比如：当代码编辑器中的文字发生变更的时候，工具栏上的保存按钮要置为可用状态，当保存后，保存按钮又要置为灰色。这样的功能是通过一个Observeor模式来实现的，这就避免了业务模块对用户界面的依赖，并且这样的模式也便于同时将消息发送给多个对象，比如保存按钮不仅要在工具栏上出现，也要在菜单上出现，这样的变化是不会影响业务模块的。在SharpDev中，这个交互的过程也是在业务模块对外提供的Service中通过delegate来实现的。

很多应用程序采用的是另一种控制模式：每个画面和窗口使用自己的控制器。在窗体程序中，这样的方式实际上就将用户界面和控制器融合在一起了，比如MFC中的Document－View，View不仅实现用户数据的展示和输入数据的收集，还要将用户的输入进行基本的处理，转变为业务模块了解的类型，调用业务模块进行处理，最后跳转到别的窗口。

在ASP.NET中使用code behide的编程框架，实际上也是为每一个用户界面采用了一个独立的Controller，aspx文件就是用户界面，对应的code behide代码就是他的控制器。这样的框架减少了程序的灵活性，但是在一般情况下可以使应用程序的框架变得简单和直接。