在我们的开发项目中使用MVC（Model-View-Control）模式的益处是，可以完全降低业务层和应用表示层的相互影响。此外，我们会有完全独立的对象来操作表示层。MVC在我们项目中提供的这种对象和层之间的独立，将使我们的维护变得更简单使我们的代码重用变得很容易（下面你将看到）。
作为一般的习惯，我们知道我们希望保持最低的对象间的依赖，这样变化能够很容易的得到满足，而且我们可以重复使用我们辛辛苦苦写的代码。为了达到这个目的我们将遵循一般的原则“对接口编成，而不是对类”来使用MVC模式。
我们的使命，如果我们选择接受它．．．
我们被委任构建一个ACME 2000 Sports Car项目，我们的任务是做一个简单的Windows画面来显示汽车的方向和速度，使终端用户能够改变方向，加速或是减速。当然将会有范围的扩展。
在ACME已经有了传言，如果我们的项目成功，我们最终还要为ACME 2 Pickup Truck 和ACME 1 Tricycle开发一个相似的接口。作为开发人员，我们也知道ACME管理团队最终将问“这样是很棒的，我们能够在我们的intranet上看到它？”
所有的这些浮现在脑海中，我们想交付一个产品，使它能够容易的升级以便能够保证将来我们能够有饭吃。
所以，同时我们决定“这是使用MVC的一个绝好情形”
我们的构架概要
现在我们知道我们要使用MVC，我们需要指出它的本质。通过我们的试验得出MVC的三个部分：Model，Control和View。
在我们的系统中，Model就是我们的汽车，View就是我们的画面，Control将这两个部分联系起来。
为了改变Model（我们的ACME 2000 sports car），我们需要使用Control。我们的Control将会产生给Model（我们的ACME 2000 sports car）的请求，和更新View，View就是我们的画面（UI）。
这看起来很简单，但是这里产生了第一个要解决的问题：当终端用户想做一个对ACME 2000 sports car一个改变将会发生什么，比如说加速或是转向？他们将通过View（our windows form）用Control来提出一个变化的申请。
现在我们就剩下一个未解决问题了。如果View没有必要的信息来显示Model的状态怎么办？我们需要再在我们的图中加入一个箭头：View将能申请Model的状态以便得到它要显示的相关状态信息。
最后，我们的最终用户（司机）将会和我们的ACME Vehicle Control系统通过View来交互。如果他们想发出一个改变系统的申请，比如提高一点加速度，申请将会从View开始发出由Control处理。
Control将会向Model申请改变并将必要的变化反映在View上。比如，如果一个蛮横的司机对ACME 2000 Sports Car做了一个"floor it"申请，而现在行驶的太快不能转向，那么Control将会拒绝这个申请并在View中通知，这样就防止了在交通拥挤是发生悲惨的连环相撞。
Model (the ACME 2000 Sports Car) 将通知View 它的速度已经提高，而View也将做适当的更新。