转载之eNet论坛
下载代码C#
在我们的开发项目中使用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也将做适当的更新。
综上,这就是我们将构建的概要:
转载于:https://www.cnblogs.com/lotussoft/archive/2009/08/27/1555432.html