跪求解脱，MVC中的M让人吐血...

C#和java区都让我不满意，我想也许是web中的MVC和桌面应用MVC的不同原因吧，特来C++版求解脱...

我有以下不解

1、首先是MVC的起源，MVC的优点是将View和Model分离，并且高度重用，一看到这句话，我就想把电脑砸了，即使没有MVC,我想任何程序设计的时候，都是把业务逻辑和数据操作做成类库API形式，即然是类库，自然高度重用，我是做.net的，.net中建了类库，哪个项目都能用，MVC的优点，这算哪门子事...

2、MVC中M的作用，在web领域的MVC中，大都数人理解的是DAL和BLL的结合，也就是操作数据库和业务逻辑，那也算就是一个类库了，这算哪门子MVC。

3、MVC中的model有一句话是这么说的："模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变"，悲剧了，我理解了半天，都无法理解模型中数据的变化,模型是一些操作数据和业务逻辑的方法函数，模型中哪来的数据，又哪来的变化，model怎么会变动呢？？

模型本身就是对数据的封装，任何对数据的读写操作都由模型来完成，说“模型中数据的变化”一点都不为过。如果把硬盘中的文件当作数据，那么文件分配表就是该数据的模型，FAT/NTFS就是不同的数据管理模型。

控制器是模型和视图之间的纽带，它是MVC框架的核心，用来提供业务流程和控制逻辑，包括你说的刷新机制（典型的观察者模型）。如果把模型当作对数据的归类和访问，那么控制器就是用来决定数据流向、过滤和分发的方式。Windows系统采用文件管理API来控制所有对文件的访问，并用COM、注册表等方式提供注册、通知机制。

视图是数据的表现形式。一个数据可以具有多种视图。在桌面的资源管理器窗口中，同样是一个文件夹下的文件集合，你可以用图标来表示，也可以用列表、详细信息、缩略图等来表示，这就是不同的视图。

视图向控制器发出指令，并接收控制器的调度和指令结果，把获得的数据按照自己的模式组织在一起，用自己的模板渲染出来。在资源管理器中，你可以通过文件管理API或者COM接口操作各种文件，获得需要的数据。

有时一种数据模型需要同时被多个视图访问，一个视图对数据的更改需要同步刷新到其它视图中。如果你同时打开两个资源管理器窗口并定位到相同的文件夹，但采用了不同的视图，当你增加或删除文件时，结果信息会同时在另一个资源管理器中体现出来，这就是所谓的同步刷新机制。当然，在Windows中，这是通过COM连接点或者SHELL API注册事件通知来达到的，它的调度由控制器来完成。

数据模型和视图都是最小的单位，一个完整的界面往往需要一个布局模板同时渲染多种数据和多种视图。资源管理器窗口就是一个布局模板，它可以在一个窗口里同时显示文件列表视图和缩略图视图，布局模板可以用任何方式来定义，比如INI、注册表、XML。资源管理器窗口就是通过desktop.ini来描述窗口布局的。

MFC中早已存在的文档-视图模型就是MVC的雏形，但它省略了C。

敲字真累……希望对你理解MVC有用。我最早接触MVC也是从WEB开始的。

我觉得还没解释清楚，简单地说：模型是数据的组织方式，并不是单纯的存储和读取，在WEB中，模型可以简单概括为数据库表结构设计（因为数据基本都在数据库里）。数据组织方式不同，解决的问题也不同。

1. API的复用是微观层面的复用，MVC里面Model的复用是宏观层面的可复用，两个关注的复用点不一样的。举例说明：Windows API和MFC，一个是底层，一个是框架。差别在哪里呢？用线性代数类比的话，API提供的就是基向量，而MFC提供的则是基向量的各种组合。也就是说，凡是你用MFC能完成的事情，用API都能完成，但是这需要你自己重头组合一次，效率一般就比不上MFC（我说的是一般情况）；但是你用MFC搞不定的事情（Windows平台），那么就非API不能完成，因为MFC不可能提供所有的基向量组合。这就需要你自己来设计怎么用这套API组合出具体的业务逻辑。
一个设计的好的库，一定要包括基本的API，也就是基向量，能让你在这个平台上无所不能；同时也要提供各种丰富的框架，也就是各种基向量的组合，能让你最大限度避免重复造轮子。
MVC模式中Model就是组合后的基向量。各种不同的业务逻辑都有不同的Model，而基本的API不可能穷尽这些Model（而且这也不是API应该做的事，API只负责提供基向量，提供接口，组合则是由程序设计者完成）。所以MVC里面的可复用就是这个意思。
2. 你讲的没有错，确实就是类库了。因为MVC里面的M就是针对特定业务领域利用基本的API进行的逻辑组合。web领域如此，其他领域如果适合的话，同样可以用这个方式进行组合。而且请注意一点，个人认为MVC模式的最大优点不在于可复用，因为它本身是API的组合，复用性再高也高不过API，所以不如说是“减少重复劳动”更为妥当。MVC的最大优点，个人认为是解耦。也就是把业务逻辑和它的表现方式分离，让Model不依赖于View的变化，或者至少让两者可以独立变化，不至于View变了，导致连Model的接口也要跟着改。因为针对具体的业务逻辑，Model一般是相对稳定的，而View则是易变的。程序设计者地职责，就是封装这种变化，把变化带来的改动降低到最少。MVC提出来的出发点主要是为了解除Model和View的耦合，复用性则是第二位的。只有耦合度最小，维护成本才能最低。解耦的方式有很多，MVC不过是众多方式中表现的比较出色的一种而已。所以建议理解MVC的时候，应该主要从使用的目的上来理解，如果不清楚目的而使用的话，其结果就是我们经常谈到的“为模式而模式”，也即是“模式误用”，效果还不如不用这个模式。
3. 关于模型中数据的变化，7楼已经解释的非常清楚了。你要理解MVC这种机制的话，就首先要理解“观察者模式”。只有理解了这个模式你才能知道MVC中的M为什么是这个样子而不是其他样子。
如果View是上层的话，Model就是底层。一般而言，都是上层来调用底层的API。但是在某些时候，底层可能需要反过来回调上层的接口，这样就是一种双向依赖。MVC里面的M之所以使用观察者模式，就是为了最大限度解除这种依赖（请注意是最大限度，而不是完全消除，因为不可能100%的消除）。具体的做法，就是为View定义一个回调的接口，然后在模型中保存下来（C++里面的一种经典实现方式就是函数指针）；等到Model的数据发生变化了，而此时又需要及时在View上表现出这种变化的时候，就利用这个回调接口通知具体的View来完成更新。至于这个回调接口是怎么实现的，则是View的职责了，Model只需要负责通知到View就OK了。
举例说明的话，如果你是领导，开会的时候的稿子一般都不会亲自写，而是通知你的秘书完成，具体怎么写出来的你不需要关心，你只负责通知秘书就OK了。所以秘书是领导背后的脸（View），领导则是真正的策划者（Model）。

一点理解，共参考。

考虑这样两个case，统计人口分布［0－20，21－40，41－60，大于60］，统计人口地区分布［beijing，上海，etc］
1，如何获得各区间的人数，及在总人数的比例。这个是M的工作。
2，如何显示这个比例，用表格，圆，图等形式来显示。这是V的工作。
3，何为重用，如果你一开始开发一个“显示百分比的图程序”，只是给人口分布用的。但如果有一天，boss让你统计各员工来之什么地方。那你开发的“显示百分比的图程序”就可以直接在这里直接使用了。
4，模型变化，这个变化是外部通知M的。假如我们上面员工分布例子的例子中，有一个Table View，里面用户的信息。假如我们认为加人表示来了新人，删人表示离职。那我们的在View上的add，delete操作就要通知Control，Control就要通知M。这就是你想说的哪个模型变化。
5，模型收到变化信息后，就可以直接通知注册的V，V收到后就可直接修改显示，而不用关心具体的变化数据。
6，灵活性，这个模型你想加几个View都可以，只要注册到M上就可以。表格看的不爽，可以加个图表示的，页可以加个用柱子来表示的。

MVC是三个单词的缩写，分别为： 模型(Model),视图(View)和控制Controller)。

简言之，高内聚，低耦合。

只有用过你才知道，那个叫爽，那高内聚，低耦合，那个分层清楚，思路清楚，简单什么都来了。一个字爽

LZ要理解MVC，先要看看MVC是解决什么样的问题的。
去找这样的程序看看：
在页面展示的代码里面，充斥着数据库的连接，sql语句，if判断。
在业务处理的逻辑里面，充斥着字体调整，颜色设置，位置设置。
面对着这样的程序，想想如果我要调整数据的字段，需要改变哪些代码，如果我要调整字体/颜色，需要改变哪些代码。
理解了这样的问题，再想想如果你来做系统的设计，会怎样？

MVC本身就是一个抽象的概念。对于任何东西都适用。就好比UML图也可以用于任何场合。（当然，这里所谓任何场合的意思，就是不限于电脑程序设计）。

MVC只是一个概念上的东西，对于具体的实践只具备指导作用。就如同MFC，它本身也并不完全是M.V.C三者全部分离的。它只是把V分离了出来，而M和C是整合在一起的。

模型(Model),视图(View)和控制Controller)
我来试着给你解脱一下，
模型(Model)一般指的是 业务模型 + 数据模型
视图(View)其实是一种结果的表现形式
控制（Controller）用来接收请求，并作出给予何种回馈的决策。

1.先讲重用（其实您这里理解的重用是狭义的代码/函数复用）
  打比方：打比方你报考一所大学（分数能上），
  a.大学收到你的志愿（请求）
  b.大学招生办（控制）它会请求学校里很多部门协调作出决定（业务逻辑）。
  c.大学招生办根据这个决定给你回复。
    被录取/未录取
    i：  招生办可能打电话通知你被录取了
    ii:  招生办可能通过写信告诉你，你被录用了
    iii：招生办可能通过电子邮件告诉你，你被录取了

  招生办通过什么手段通知你，这便是一个控制。
  你得到信息的表现形式，便是一个视图。
 
就这么多先