http://damoqiongqiu./blog/1949256 ---比较Backbone和Ext4.x在MVC实现上的差异 前言圣人云:不想做妈咪的小姐不是好码农。 每一个码农的心中都有一个终极理想,那就是有一天不用再Coding。 在成为妈咪的道路上,“设计模式”被认为是一项必备的技能。 因此,经常有湿主会问小僧这样一个问题:为什么MVC不是一种设计模式呢? 对于这样naive的问题,小僧向来是嗤之以鼻的,你们啊!图样图森破! 机缘巧合,前段时间在焦点技术大会上听到一位大牛关于Backbone的介绍,于是小僧最近一段时间研究了一下Backbone相关的内容。 在《Developing Backbone Application》(戳这里查看此书电子版)这本书上,恰好有几段关于MVC相关的内容,看完这段内容之后,小僧突然有醍醐灌顶之感。原来为什么MVC不是一种设计模式这个问题还真的是个问题,看起来是小僧自己执念太重了! 罪过罪过。 弥陀佛~~! (淘宝的一位牛人白汀 @白汀UX 翻译了《Developing Backbone Application》这本书,完整的在线电子版请戳这里,小僧友情建议一下这位大牛,请注意翻译质量,错别字和语句不通顺的问题太多了点!) 为了让各位道友也能领悟到设计模式里面的一些奥妙,小僧特作此文。 稍安勿躁,让小僧给各位湿主解说一番。 (这里就不对着原文翻译了,为了方便各位道友理解,小僧总结一下其中的精髓,E文好的请点浏览器右上角。) MVC的起源1979年,Trygve Reenskaug 这位牛人在Smalltalk-80系统上首次提出了MVC的概念,最初的时候叫做Model-View-Controller-Editor。 (我擦,1979年小僧还在佛祖那儿念经呢吧?) 1994年,Gof(Gang of Four)在《Design Patterns: Elements of Reusable Object-Oriented Software》一书中对MVC模式做了深入的解析。 Trygve Reenskaug最初提出MVC的目的是为了把数据(Model)和视图(View)分离开来,然后用控制器(Controller)作胶水来粘合M和V之间的关系。 很显然,这样做的目的是为了实现注意点分离这样一个更高层次的设计理念,也就是让专业的对象做专业的事情,View就只负责视图相关的东西,Model就只负责描述数据模型,Controller负责总控,各自协作,别总掺和到一起乱成一锅粥! 最古典的MVC实现请注意上一小节中的两个年份,1979年,计算机还不是屌丝能玩儿得起的东西!那时候比尔盖茨还是个小学生,并且他还没有辍学创办MicroSoft,那时候人们不知道什么是Windows,当然,也没有什么GUI的概念。 各位道友可以想想一下,黑黑的命令行,一串一串的文本字符... 嗯嗯,就是那个样子的! 显然,在这样的历史背景之下,原始的MVC模式显然不是如今所理解的那种样子。 在Smalltalk-80上的那个古典实现上,View和Controller都是要监听Model的,也就是说,只要数据发生变化,视图和控制器都会收到通知的! 也就是这个样子的: C和M,V和M之间都是通过Observer pattern (观察者模式)来实现的。 对于这种古典的实现细节,请参见Martin Fowler的这篇文章。 为什么GOF的23种设计模式里面没有MVC?好了,到这里应该来解释为什么MVC不是一种设计模式这个问题了。 对于这个问题,直接引用@白汀UX 的译文如下:
嗯嗯,知道为什么MVC没有被GOF当作【一种】模式来对待了吧? 因为它实际上是三种模式的合体! (如果以后有人问你这个问题,你可以直接引述上面这段话,绝对高端大气上档次!一下就能把TA给震住!) 前端MVC与经典MVC的差异正如前文所述,在当初提出MVC这种设计理念的历史条件之下,基本上还没有图形界面,当然像JavaScript这种东西也是不存在的! 但是,如今不同了!在如今前端框架(尤其是各种JavaScript框架)大爆炸的背景下,几乎所有的框架都会号称自己具有MVC的特性。 但是,有一点请注意,如今的MVC实现与古典的MVC实现方式已经大不相同了。 下面拿Backbone和Ext来举两个例子。 Backbone中的MVC实现方式对于最新版本的Backbone来说,它不再区分出独立的Controller,它的控制器代码与View是写在一起的,仅仅明确区分出了Model的概念,举个栗子: 呃,请不要在意那些细节,看红框的部分即可。 第一处,显然Employee是一个Model; 第二处和第三处,显然那EmployeeView是一个View; 第四处,setText这个方法显然是充当Controller的角色。 很显然,在Backbone的这种实现之下,View和Controller合体了,并没有抽象出独立的Controller这种东西。 显然,这是古典MVC的一个变种,也就是原书作者所谓的MV*。 各位道友请仔细想想,Backbone的这种做法有没有道理? Ext4.x中的MVC实现再来看Ext4.x中的MVC实现。 从以上示例项目截图(controller/model/view等目录)可以看出来(此图来自Ext官方的说明文档),Ext4.x采用了古典的MVC设计方案,它明确地抽象出了Controller这个类。 为什么小僧坚持认为Ext4里面的MVC是一种过度设计?熟悉Ext历代版本的道友会知道,在Ext4.x之前,并没有做出前面这样的区分。 【以下纯属个人看法,仅供参考】 与Backbone相比,Ext4.x的这个设计纯属鸡肋,实际上,对于带有GUI界面的代码来说,Controller是无法独立于View而存在的。 因为,在Controller里面一定需要到处访问View中的内容,Controller是无法独善其身的! Ext4.x的这个实现为了MVC而MVC的一个绝佳例子。 在Ext4.x中,类似为了模式而模式的例子不胜枚举,据小僧不怀好意的推测,这一定是Jack离开之后这帮人乱搞的结果。 这也是为什么Ext4.x的运行效率如此之差的原因,之一。 小僧都替你们捉急有木有?!!! 对于4.x的效率问题,网上的吐槽不计其数,各位道友可自行咨询度娘。 为什么小僧认为MVP/MV*才是最佳设计理念这里请区分好概念,设计理念和具体实现方式不是一回事。 在关于Backbone的这本书中,作者还提出了MV*和MVP (Model-View-Presenter) 的说法,不得不说,这是非常具有洞察力的见解。 其中的Presenter可以用来与服务端交互,获得Model数据,以及把Model提交到服务端等等。 在当前MVC很多的实现里面,与服务端的交互是写在Model里面的(Backbone和Ext都是这样)。 小僧认为,这种实现方式有待商榷,如果在Model里面含有后台交互的代码,在不同的场景下显然无法达到复用Model的目的。 比如,在场景一下面你希望数据模型访问 myApp/delUser.action,而在场景二下面你希望它访问 myApp/daddUser.action,这种情况你就麻烦了不是? 而且,与后台的交互过程应该抽象成独立的数据传输层,在这一点上Ext的实现略好。 因此,MV*、MVVM、MVP都可以看作MVC的现代衍生版,M和V一定要明确区分,至于要不要抽象出其它类,其它类是应该和M合体还是应该和V合体,各位道友看着办即可! 结语当初提出MVC,是为了实现关注点分离这样一种设计理念,MVC只是实现这一理念的一种方式而已。因此,不必拘泥于一定要抽象出Model/View/Controller这样的类结构。 学习模式!运用模式!超越模式! 心中无码,一切都无码! 弥陀佛~~! |
|