Document-View与MVC

MVC理解（借用XX百科上的定义）：

视图（view）：数据的展现。

视图是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行任何实际的业务处理。视图可以向模型查询业务状态，但不能改变模型。视图还能接受模型发出的数据更新事件，从而对用户界面进行同步更新。

模型（model）：应用对象。

模型是应用程序的主体部分。 模型代表了业务数据和业务逻辑； 当数据发生改变时，它要负责通知视图部分；一个模型能为多个视图提供数据。由于同一个模型可以被多个视图重用，所以提高了应用的可重用性。

控制器（controller）：逻辑处理、控制实体数据在视图上展示、调用模型处理业务请求。

三者表现关系如下

 

Document-View(MVC方法论在MFC中的实践)：

我认为Document-View是MVC方法论的一次实践（虽然不太成功）。MFC作为一个FrameWork实现这一结构，定义了诸如CDocManager、Document template、Document、Frame、View等类型。程序的存在是为了处理数据，我认为这个框架中Document才是一切的核心。CDocManager与Document template 是为了配合Document类存在的（同时Document template还关联了相对应的Frame和View）。Frame与View则是为了显示数据与用户交互而存在。

此图大体展示了这几个类之间的关系。

 

Document-View与MVC:分别了解完Document-View与MVC后，发现他们的采用类似的思想（方法论）都意图把数据，逻辑，显示分离开来。（什么？MFC不这么干？没有么？真没有么？）

关于两个结构的数据部分相对应MVC总的model，MFC中改了个可怕的名字叫Document。毫无疑问这个类型是用来保存和处理数据的。提供状态查询接口（函数？我也不知道这个函数叫什么），和更新通知机制（看那一串ViewList，Update的时候你知道怎么做的）。

接下来就是逻辑部分了。在MVC中这个部分应在Controller中实现。但是，这种时候总会有但是，Document-View的Controller呢？貌似只有数据跟视图两个部分。相同的思想实现方法各不相同罢了（难道我会告诉你美国佬是用选票推翻他们的现任政府的？）。首先需要分析Controller是做什么的？定义应用程序行为、用户动作映射成模型更新、选择相应的视图、与功能一一对应。以单击画点为例，此为功能，定义程序行为当然是处理单击这一动作的过程，用户动作映射成模型更新理解为将点的位置保持到model中，选择相应视图则应当是为了在视图中画出。在MFC中为实现此功能要先添加单击事件的响应函数（定义程序行为），在响应函数中将点位置保存起来（用户动作映射成模型更新），再DC输出（DC能理解成视图？勉强应该可以吧）。OK，这些功能貌似都可以在View中实现么，所有这些处理都在View类型中实现了。由此可见View对应MVC中的Controller（靠，美国佬到底会不会英语啊？：P）。

既然MFC中的View类型干了MVC中Controller的事情，那真正的View去哪了？同上分析，MVC的View的能力主要有显示和用户交互，显示就是在屏幕上输出，用户交互就是接受用户输入并讲请求通知给Controller。在MFC中给CView类型发送的请求的操作系统，是不是可以将操作系统的一部分视为View（你说谁是View？谁应我说谁 ：> ）。

 

至此Document-View与MVC终于一一对应起来了，虽然某些地方联系的比较牵强，不过在之后的设计中不必再为将逻辑处理代码写在CView类型中耿耿于怀了。反正MFC的这个结构遭人诟病也不是一天两天了，方法论在实践过程中的因为环境的不用终究不可能做的十分理想，把责任往MFC上推好了。