作者写的非常好,忍不住转载一下!
原文出处:http://blog.csdn.net/absurd/article/details/1434042
作者联系方式:http://blog.csdn.net/absurd
作者联系方式:Li XianJing <xianjimli at hotmail dot com>
更新时间:2006-12-19
像名片、日程、任务、短信、文件浏览器和多媒体播放器等应用程序,都采用MVC模型作为其基本架构。但从这段时间的文档评审来看,我们对MVC模型的理解仍然存在一些误区。这里简单谈一谈,欢迎交流。
先说两句题外话,免得少数网友替我着急。他们会说,拜托,你写点新内容好不好,不要用MVC这类老掉牙的东西来充数。呵,很多人都热衷于新技术,我以前也一样。经过五六年的学习和实践后,让人遗憾的是,我没有发现什么真正的新技术。相反,倒是一些”老”技术充满魅力。包括像汇编语言、C/C++、awk/bash、计算机组成原理、操作系统原理、数据库原理、编译原理、数据结构、TCP/IP实现、面向对象、设计模式、POSA、代码重构、自动测试、人机交互,RUP/XP等比较通用的知识,也包括像linux、apache、xerces/xalan、GTK+/X/glib、STL/boost、MFC、COM/DCOM等这样特定平台/函数库。根据自己的经验来看,了解一项技术的基本内容并不难,难点在于灵活应用它们,在于适当的时候选择适当的技术。个人认为,把目前这些”老”技术掌握好了,无论是设计还是编程,完全可以做到游刃有余的境界(我还在努力中)。相反,整天只关注所谓的新技术,对一些经典技术反而只了解皮毛,可以说是捡了芝麻丢了西瓜,得不尝失。道不同不相与谋,热衷于新技术的朋友可以在此打住了。
好了,言归正传。下面是我在我们平台中发现的一些问题:
1. 把控制器(Controller)和模型(Model)混在了一起。MVC模型的三大部分中的控制器(Controller)是最容易让人混淆的,在基于窗口的GUI应用程序中,控制器(Controller)一般就是控件的事件处理函数。控制器(Controller)有两个基本功能,一是把用户从界面上的操作(点击按钮)映射成模型(Model)对应的功能(如删除数据),二是把模型(Model)的变化更新到视图(View)上。控制器(Controller)和视图(View)的耦合比较紧密,尽管可以用策略模式来实现多个控制器(Controller)之间的切换,但那样做,实现复杂而且没有多少好处,所以很少有人去分离控制器(Controller)和视图(View)(据说WEB开发例外)。然而Glade把产生的事件处理函数放在callbacks.h/.c中,把产生的界面代码放在interface.h/.c中,这看似把界面与实现分离了,使得一些同事误以为callbacks.h/.c中的代码就是模型(Model),所以把控制器(Controller)和模型(Model)混一起了。结果是模型(Model)包含了一些控件,没有做到与界面的分离。
2. 所有界面与模型(Model)关联。有的界面是比较独立的,完全可以以一种调用关系来实现,结果也与模型(Model)挂了钩。这看似充分利用了模型(Model),实际上是把模型(Model)当成了全局变量的替代器。结果是一方面增加了界面与模型(Model)耦合,让这些独立的界面难以重用,同时也增加了模型(Model)复杂度。
3. 认为一个应用程序只能有一个模型(Model)。大部分应用程序都只需要一个模型,但一些同事把这个现象这看成了定论。其实模型(Model)是一个逻辑上的概念,如果几个视图和另外几个视图毫无关联,最好各自使用独立的模型(Model)。否则把多个模型(Model)绞在一起,造成不必要的耦合,使用代码重用困难,也让增加模型(Model)的复杂度,使实现的难度增加。
4. 认为模型(Model)是一个不可再分的单元。在一些设计中,界面无关的实现代码的确与界面代码分开了,但它们都放在模型(Model)里,模型(Model)成了一个庞然大物。我们说了,模型(Model)只是一个逻辑上的概念,甚至完全可以没有模型(Model)这个名字出现,其架构仍然是基于MVC的。模型(Model)的责任一般要进一步划分,把责任分配多个更专业的类上。否则模型(Model)会过于复杂,使实现的难度增加。