跟着微软走，不会MVC，你OUT了

益处

在我们的开发项目中使用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也将做适当的更新。

综上，这就是我们将构建的概要：


开始：

作为总是想的远一点的开发人员，我们想让我们的系统有一个长久并且良好的生命周期。这就是说能够进可能的准备好满足ACME的很多变化。为了做到这一点，我们知道要遵循两条原则．．．“保证你的类低耦合”，要达到这个目标，还要“对接口编程”。

所以我们要做三个接口（正如你所猜测，一个Model接口，一个View接口，一个Control接口）。

经过很多调查研究，和与ACME人的费力咨询，我们得到了很多有关详细设计的信息。我们想确定我们可以设置的最大速度在前进，后退和转弯中。我们也需要能够加速，减速，左转和右转。我们的仪表盘必须显示当前的速度和方向。

实现所有这些需求是非常苛刻的，但是我们确信我们能够做到．．．

首先，我们考虑一下基本的项目。我们需要一些东西来表示方向和转动请求。我们做了两个枚举类型：AbsoluteDirection 和 RelativeDirection。

  
最后但不是至少
    现在我们的"ACME Framework"已经做好了，我们只需要设立有形的类和接口。首先让我们看看最后两个类：Control 和Model...
    这里我们有形的AutomobileControl实现IVehicleControl接口。我们的AutomobileControl也将设置View来依赖Model 的状态（当有向Model的申请时检测SetView方法）。

    注意，我们只是有对IVehicleModel的引用（而不是抽象类Automobile ）和对IVehicleView的引用（而不是具体的View），这样保证对象间的低耦合。


 
       如果我们想让我们的ACME2000 Truck变得迟钝，只需要在AutoView中包装。
private void btnBuildNew_Click(object sender, System.EventArgs e){this.autoView1.WireUp(new ACME.SlowPokeControl(), new ACME.ACME2000Truck(this.txtName.Text));}
      最后，如果我们需要一个在web上的接口，我们要做的所有工作就是建立一个Web项目在UserControl中实现IVehicleView接口。
  
结论
        正如你所看到的，使用MVC来构建代码控制接口耦合性很低，很容易适应需求的改变。它也能使变化的影响减小，而且你可以在任何地方重用你的虚函数和接口。有很多时候我们可以在我们的项目中实现伸缩性，特别是在那些需求变化的时候，但是这需要下次再说了。
        于此同时，做下一个项目的时候记住MVC．．．你不会感到遗憾！
        Happy Driving.
 
11楼hky198808243分钟前
其实也要看哪方面的项目  如果是小型项目的话我觉得mvc真的不适合  传统的模式更加合适小型项目 开发更加直观 但是项目大了的话mvc比较合适
10楼sbjbmgj0963147分钟前
切,微软的MVC就是个鸡肋，垃圾n不能彻底分离
9楼qdu1237小时前
说实话，MS的MVC，弄很多代码在页面中，对前台人员真的不好，干扰太大，还不如Jquery+webservice呢
8楼sniffer123459小时前
[quote=fwj380891124]回复unistdn这位仁兄貌似对微软有很大的成建，首先澄清一下，发表这篇文...[/quote]n我记得三年前ms就推出.net mvc了吧？
Re: fwj3808911247小时前
回复sniffer12345n嗯，2009年推出的
7楼BEYONDMA11小时前
[quote=unistd]我操他妈啊，这样的文章竟然也能放到CSDN首页，可见CSDN水平一般啊。nn这题目弄得好像MVC是微...[/quote]n其实MVC和MICROSOFT还真是没多大关系，MS的WIN32框架实现其MVC来也很麻烦。但是我觉得楼主文章不错啊，言之有物。unistd 如果是UNIX的铁粉，分享一下也笔直接国骂好啊。
6楼lishehe12小时前
lz强悍！加油
5楼hannover100昨天 14:14
最近在学习通过TDD的方式来开发带界面的项目，与MVC有很多类似的地方，那就对界面、逻辑、数据进行了分离。nn只是感觉这种TDD的开发比MVC分离得更彻底：n    UI -- Presenter-- BusinessLogicn    （Presenter包含了MVC中的Model部分）n    界面UI仅仅负责布局也就是美观问题n     Presenter衔接了UI与BusinessLogic对界面的操作，都委托给Presenter中的方法,Presenter处理的结果推送给UI来显示
4楼hesi726昨天 13:09
晕，俺想问问，不用MVC，直接用 DataSource 之类的，代码量可以节省多少？？n微软推出MVC（现在应该已经到 3.0了吧）并不是认为MVC有多好，只是，呵呵，大家都知道的，别人没有的，我也要有；别人有的，我更加要有；
Re: fwj380891124昨天 13:09
回复hesi726n用了MVC，代码量肯定比直接再.cs文件操作少很多代码。MVC只是一种简化开发的模式，适合团队协作开发，用了设计模式同样也会增加代码量，但是大家都在学，为什么，用的就是一套规范。微软推出MVC，也是为了更好的实现界面和代码分离。C
Re: unistd昨天 14:12
回复fwj380891124nn小子，等你都写几年代码，都接触一些框架，再来放什么“MVC，代码量肯定比直接再.cs文件操作少很多代码”，“适合团队协作开发”这样的屁话行不行？
3楼Ahyoomi昨天 11:37
MVC和微软 没关系吧。。
Re: fwj380891124昨天 11:50
回复AhyoominMVC只是一种模式,不限语言
2楼hky19880824昨天 09:18
其实也要看哪方面的项目  如果是小型项目的话我觉得mvc真的不适合  传统的模式更加合适小型项目 开发更加直观 但是项目大了的话mvc比较合适
1楼unistd前天 18:51
我操他妈啊，这样的文章竟然也能放到CSDN首页，可见CSDN水平一般啊。nn这题目弄得好像MVC是微软发明的似的。而事实是，MVC是上个世纪80年代就有的，在非微软平台得到普遍应用的一个模式。nn微软后来一看自己那一套不行了，不得已也搞起了ＭＶＣ。nn而且ＭＶＣ有很大的问题，不是一个好的模型。
Re: fwj380891124昨天 08:42
回复unistdn这位仁兄貌似对微软有很大的成建，首先澄清一下，发表这篇文章的目的，是想让更多跟着微软走的朋友们来了解MVC模式，而并非你说的MVC是微软发明的。其次，至于微软为什么会推出MVC框架，有什么大的问题我并不关心，我只关心微软推出这套架构对我工作带来的便捷。每种模式都有它的局限性，只是看你能不能选择一个对自己有帮助的。还有，麻烦老兄下次对自己的言词注意下，不要动不动都是脏话，这样体现不出来你的伟大，只能被后人们看做笑柄罢了。至于CSDN的水平怎么样，我不做任何评价。还是那句话，只选对的，不选贵的。