佳为好友

原:关于MVC中C的​讨论,以及MFC是否​能够模仿Struct

创建:2009年12月26日

关于MVC中C的讨论
一,关于C有三种实现,比较它们的不同。
关于C有三种实现:MFC中的View或Dialog;iPhone中的Controller;Java的Struct的Action;
*MFC中的View实现的最简陋了。它既包含C的成分,又包含了V的成分(例如,保持View在最前端等等)。
对于程序后添加的按钮等控件,则保存在了RC文件中,但是RC文件的改变是需要重新编译的。
*iPhone中的Controller前进了一步,它把Controller的部分完全独立了出来。它与MFC的主要区别是:MFC使用类的继承,在View的子类中添加了Controller的逻辑。而iPhone则使用接口和组合将C的逻辑独立出来。
并且,对于程序后添加的按钮等控件,则保存在了NIB文件中。对NIB的改变不需要重新编译。
--缺点是:IPhone的Controller还是捎带着牵连进来了一部分View的逻辑。例如需要在响应函数-(IBAction)xxxx:(id)sender中操作sender,而sender就是GUI因素,需要通过它来得到空间的内容。而且还需要利用IBOutlet来改变界面,而IBOutlet也是GUI界面。而且在View中还需要如UIAlertView来提示客户。这些缺点导致对于Controller还是无法进行测试的。
*Java的Struct则更前进了一步。Struct中C的逻辑是完全放到Action中的,而且Action中一点View的逻辑都没有。它可以独立测试。
它是怎样实现的呢?过程如下:1,客户端点击某个表单的按钮--->2,IE将其发送到WebServer--->3,WebServer调用Struct--->4,Struct根据HTTP协议解析表单,并将其内容保存到全局区间--->5,Struct根据请求的Action的名字读取配置文件得到响应的Action,并调用--->6,Action向全局区域获取想要的内容--->7,Action操作之后,将结果添加到全局区域,并返回相应View的名字--->8,Struct得到View的名字,然后根据配置文件调用相应的View--->9,View也向全局空间得到自己需要的内容,并显示--->10,Struct将View发送给客户端。

二,讨论我们是否能在MFC和iPhone中模仿Struct。
答案是不能。直接原因有4个,根本原因有4个。
直接原因是:1,需要编写大量代码,降低开发时间;2,不容易维护和调试;3,代码逻辑混乱;4,增加运行开销;
根本原因是:1,界面逻辑不同;2,协议标准不同;3,语言特性不支持;4;不必要。
*首先将根本原因1-界面逻辑不同。例如在单机GUI中时常需要弹出对话框,但是对于Struct面对的Web环境,则不需要弹出对话框,或者说所谓的对话框也是通过View来实现的。它不能通过一个关闭按钮回到原来的状态中,只能点击IE上的后退按钮;同时,对话框有那种弹出的效果,而Web页面则是并列的关系,虽然在MFC中也能这样做,但是这会让用户十分不习惯,同时也要多写很多代码。
这就导致,如果需要提示对话框,Action则直接返回一个View的名字,而MFC则不能这么做,即使能这样做,也将非常麻烦。
*其次讲根本原因2-协议标准不同。Struct使用HTTP协议返回客户表单,因此Struct能够自动化的处理表单,并将对应的变量保存到全局区域。而MFC则没有标准,只是一个按钮触发一个操作,要获取其他控件的内容(也就是表单内容),则需要自己手动的去获得。因此,我们要想将这些内容保存到全局区域,则需要手动操作,这将导致编写很多代码。但是这一原因其实并不能算是不能模仿Struct的很根本原因,为什么呢?因为即使不模仿Struct,MFC也还是要执行这个操作的,因此无论是否模仿,这个操作都避免不了,因此说它不是影响模仿Struct的根本原因。
*其次讲根本原因3-语言特性不支持。MFC不支持反射,和通过名字创建对象。这将导致后面的直接原因。
*其次我们将讲全部的4个直接原因。让我们先假设模仿Struct,然后说说哪些影响了开发效率。
要模仿Struct,即将所有的逻辑都放入Action中。这有三种实现方法:
a,Action子类的成员函数中保存了所有它需要的所有内容,然后由Controller在调用的时候负责赋值,内容来自两方面,一是当前控件内容的;另外一方面是全局空间原有的内容的。
然后,Controller还要负责把Action执行的结果读出来写入控件,并把需要保存到全局空间的内容写入到全局空间。
--缺点是:1)全局空间的内容本来是各个Action通用的,而这种方法导致Action中额外多几个成员变量保存全局内容。2)对于全局空间的赋值也是额外的操作,包括向Action赋值,以及读取Action的值写入全局空间。--这两点的工作量,以及空间和运行效率都降低了,并且也要增加大量的工作量。
b,针对a的改进是,将全局的内容统一保存到一个公共的全局类里面,每个Action都有它的一个引用。
--缺点是:1)由于全局类包含了所有公共内容,所以当任何一个Action的内容改变,需要添加或减少一个公共变量时,都将引起全部的Action的重新编译。这明显的违反了“向稳定的方向依赖”这一原则。这一方法肯定是错误。
c,针对b的改进是,仍然使用全局类,但是类的成员变量使用一个Map,是公共成员名到它的内容的映射。这样,添加新的公共变量时,不需要改变全局类,所以全部的Action也不用重新编译了。
--缺点:1)导致所有的公共变量失去了类型标记。每次赋值和取值都要各进行一次类型转换。这与原来的MFC程序相比,不但增加大量工作量,而且容易出错。但是Struct却也是忍受了这种工作量和这种可能出错的危险。)2)也不便于调试。比如,在VC6.0中我们查看Map的内容十分费劲;同时,由于公共变量是动态加入的,因此设置内存断点也比较麻烦。
--但是,Struct其实就是这么实现的。只不过编辑器和调试器给了更多的帮助。比如Struct利用HTTP协议将自动化装在全局变量的过程;调试器也可以查看全局的区域的内容;但是,它仍然要付出“不能检测类型”的风险。
*但是,我们已经和真正的Struct很接近了,因为Struct也是忍受了这种工作量和这种可能出错的危险。只要我们不介意调试器带来的不便,我们也可以这样实现我们C++版本,或者Objective-C版本的Struct。
真正的问题是“根本原因4不必要”。我们比较一下:
Struct的好处是:1,可以单独调试Action;2,Controller可以和所有Action子类解耦;3,可以使用拦截器;4,Action和View可以单独设计;
MFC模仿Struct的好处是:1,可以单独调试Action;2,Controller可以和所有Action子类解耦;
MFC模仿Struct的缺点是:1,需要编写大量代码,降低开发时间;2,不容易维护和调试;3,代码逻辑混乱;4,增加运行开销;
不必要的原因是,对于MFC和Objective-C的程序而言,程序规模小,我们对于“1,可以单独调试Action;2,Controller可以和所有Action子类解耦;”是否真的那么需要,以至于可以忍受它所带来的缺点。对于“可以单独调试Action”,由于Action的数量少,逻辑简单,我们即使在出现问题后在调试也很快就能定位,而且,必要的时候,对于一些复杂的逻辑逻辑,我们也可以再抽取出Action来进行测试,而不必所有的逻辑都用Action来实现,因此,第一个好处就不必要了。而对于“Controller可以和所有Action子类解耦”,同样,MFC很少的逻辑,即使所有逻辑都写在View中,也不要紧,所有第二个好处也没有用了。--总之,MFC模仿Struct是没有必要的。如果加入Struct只改动很少的内容,则还可以考虑一下,如果代价那么昂贵,我们就没有必要模仿它。
那么为什么对于MFC程序不必要的东西,丢与Struct程序就必要呢?因为:1)Struct是服务器程序,逻辑庞大,程序也庞大,一点点的牺牲,可能大幅度提高程序的开发效率。2)客户端发送HTTP到服务器端,无论如何服务器端也是要解析HTTP的,并保存响应的变量,而且这个过程可以自动化。而对于MFC,我们则需要手动的将控件的值写入全局变量,然后再由Action读出来,然后Action在将结果写进去,Controller在读出来。这与原来的“Controller读出控件数据,然后运算结果,然后写到控件中”这一过程相比,麻烦了不少。也就是说Struct是必要的过程,但是在MFC中却一点也不必要。

三,讨论我们可以借鉴些什么。
如果需要单独测试某段逻辑的功能。则可以使用方法a来建立一个Action,把Controller中逻辑提取出来。然后单独测试Action。

四,总结
通篇,我们最终论述了MFC和iPhone是不能模仿Struct的。附带的,我们有时可以借鉴一点,以达到测试的目的。
+++++

posted on 2012-12-15 11:03 佳为好友 阅读(303) 评论(0)  编辑 收藏 引用


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

<2012年12月>
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

留言簿(1)

随笔分类

搜索

最新评论

评论排行榜