学习.NET架构设计系列：Model–View–Controller（MVC设计模式）
最近MVC1.0正式版已经发布了。
Model-View-Controller简称为MVC，这是图形界面（GUI）应用程序的一种架构形式。Model是业务领域层，比如我们在前面两篇里面提到的Account、Entry、Bill、Invoice之类的对象，这些类构成了一个电信账务系统的业务领域层；View就是用户界面；Controller是指用户界面和业务对象之间的控制器，控制器的作用是从业务对象中获取数据显示到用户界面上，并且从界面上收集用户的输入和动作，然后调用业务对象完成业务功能。
大部分软件系统的工作可以总结成下面这样的流程：从存储数据的地方取得数据，把他们显示在用户界面上，然后用户在界面上修改这些数据，再把数据写回存储。数据在存储和界面之间来回流动。这种看似简单的分析方式经常让开发者有这样一种冲动：把界面和数据写在一起，这样可以少很多层次，少写很多代码，也可以减少运行过程的环节，似乎可以加快程序的运行效率。但是实际上，这种直来直去的烟囱式系统不能很好的隔离界面和业务代码，在开发和维护的过程中会带来很多麻烦。
把程序的界面和业务代码分离开会带来很多好处。一般的说来，界面比起业务逻辑来变化来的更加频繁一些，修改界面的时候，不应该对业务代码造成影响；开发这两个部分所使用的技巧也有很大的差别；在有些系统里面，需要为同一个功能开发多种界面，比如一个Windows窗体界面给后台管理人员使用，一个Web页界面提供给广大人民群众，还需要做一个适用于PDA浏览器的界面，如果界面和业务代码是混杂在一起的，多种界面的开发就需要做很多重复性的工作；把界面和业务代码分离开也使可以为自动化的单元测试提供很多方便，要对用户界面创建单元测试代码是十分繁杂的，而对业务代码做单元测试则是简单的，也是必要的。
于是有经验的开发者会在设计程序的时候创建一个业务领域层，在这个层次中有很多业务对象，他们直接体现了业务需求的核心。用户界面层不是自己实现业务功能，而是调用后台的业务对象。用户界面向用户展示业务对象的属性，并且捕获用户的输入，调用业务对象的方法实现各种功能需求。当业务逻辑层和用户界面层都具备了以后，剩下的一个问题就是：如何把这两个层次粘和起来――这就是控制器需要做的工作。
最简单的控制方式就是直接在界面中调用业务对象，这种方式称为Model-View模式。
Model-View模式在界面和业务模型之间建立了一种最简单的依赖关系，界面直接调用业务模型，模型通过消息这样的松耦合方式修改界面上的表示内容（比如上一篇里面使用C#语言中的事件实现告警在界面上的显示）。这样可以实现层次的分离，对改善软件系统的构架是有一定的帮助的。
使用过Microsoft Visual Studio各个版本的开发者一定对Model-View的控制方式非常熟悉，无是在VB、VC，还是后来的C#、ASP.NET中，我们把一个按钮控件拖放到窗体上，然后鼠标点击这个控件，就会自动生成一段事件响应代码。下面是用这种方式编写的一段程序，这是“非洲电信公司账务系统”的一个界面，营业员使用这个界面为用户缴费：
营业员在“号码”输入框里面填写用户的电话号码，在“金额”输入框里填写需要交的金额，然后点击“提交”按钮，就可以把钱交进账户。如果发生了异常情况，程序会出现提示。
按下“提交”按钮的时候，按钮发出Click事件，窗体可以捕获这个事件，采取响应行动。控制器就是用这样的机制实现的。
{
//按下缴费按钮，调用业务对象，实现缴费功能
try
{
string phone_no = textBox1.Text;
string money = textBox2.Text;
//根据电话号码得到用户对象
User user = GetUserByPhoneNumber(phone_no);
//得到这个用户的账号
Account account = user.Account;
//调用账号的Pay，接口给账号交钱
//Pay接口处理完费用之后要判断欠费，
//如果不再欠费向交换网络发指令，给用户开机
account.Pay(float.Parse(money));
MessageBox.Show("缴费成功了");
}
catch (Exception e)
{
MessageBox.Show(e.Message);
}
}
这种控制器叫做“页面控制器”（Page Controller），控制器的功能是融合在界面中实现的。页面控制器简单实用，代码编写量很少，所涉及的技巧也并不高深，一个初学编程的人也很快就可以掌握。在解决一个简单的界面的时候，这样的控制器是非常适用的。但是，如果需要设计的程序具有更加复杂的功能，需要设计大量的界面和功能，这样的简单方式就会带来难以控制的复杂度。