模型-视图-控制器 MVC

接着说下去前,先侃侃理论,政治课本告诉我们,理论指导实践。

事实上,我不喜欢像神棍般鼓吹模式,理念,哲学之类形而上的虚幻东西。

左一步是信仰,右一步是脑残,信仰与脑残背后隐藏着利益集团。

不过呢,了解一些忽悠小妹妹的基本术语还是很有现实意义的。

MVC,模型-视图-控制器,号经称典设计模式。

该模式Xerox PARC在八十年代为编程语言Smalltalk-80设计。

M,Model,数据模型。用结构化的数据来勾勒世界。

数据模型也是个抽象的概念,它通常由一个或多个表以及缓存联合构成。

V,View,用户视图,也就是界面。美女画皮,对于大部分地球生物来说,appearance才是第一位的。

C,Controller,代表控制器,是模型和界面沟通的桥梁。

Model是自成体系的,它凌驾于View和Controller之上。

我们可以为Model单独编写测试(PS:就个人而言,对测试持保留观点),后台运行的工具中也可以直接引用Model。

Controller依赖于Model,他好比饭馆中的备菜工,将来自五湖四海的鱼肉在案台上切细、配菜,传送给大厨 -- View。

实际开发中,M-C,C-V远非泾渭分明。

大体上,会被反复使用,又或是后台计算需要的数据集合,比如最热门的帖子,算作Model的一部分。

一次性的代码,比如数据格式的效验,归入Controller。

涉及文字显示的逻辑,比如将 “8:30:34” 转换为更友好的文字 “今晚八点半” ,则直接写入Template。

总而言之,编程不是科学,而是手艺活 -- 想想中医吧。

部分Django开发者标新立异的提出所谓的MVT,Model-View-Template的概念,但没有本质差别。

M依然是那个M;Template是网页模板,也就是用户界面;View奔波于模型与界面之间。

在IT短暂而又漫长的历史上,换汤不换药的概念股星河浩瀚,一如好莱坞的007系列电影。

不要迷恋模式,模式只是个传说。

杯具中有着洗具,MVC体现着分层。

不得不承认,分层思想能帮助在烂泥上摸爬滚打的蚁族树立正确的人生观,价值观。

世界这个庞然大物,除了少部分隐居天堂的同学,没人可以洞悉万物。一个狭隘领域,都能让最天才的家伙耗尽毕生精力。

如同做企业。当规模小的时候,亲力亲为,效率一流;当规模大的时候,如果仍然事必躬亲,绝对分身乏术。(PS:好吧,我没做过企业,本段纯属道听途说)

编程是真实世界的投影。

代码随着时间堆积,随着人世沉浮,渐渐地,没人能了解它的全部细节。

这时候就不得不面临分层的抉择。

每层保持KISS[注1],降低代码复杂度;层与层间修建防火墙,阻隔问题蔓延;低耦合,高内聚;谁都能说点条条框框。

但该不该分,怎么划分,学习成本,性能开销,配套工具,天时地利人和,无数因素需要权衡考虑。

一不小心,弄巧成拙,就是让后人诅咒的败笔[注2]。

帝王谋臣思考了千年的官僚制度,古代的科举现代的文凭制度,都是某种意义上的分层问题。

边写代码边总结思考吧,形而上的东西,可意会,不可言传。

爱迪生说:天才是百分之一的灵感加上百分之九十九的汗水。

注释:

1.Keep It Simple, Stupid 的首字母缩略字,是指在设计当中应当注重简约的原则。

2.参考:云风的 BLOG -- C++ 会议第一天
http://blog.codingnow.com/2009/12/cpp2009.html
“结果发明和维护的人走了后,用它的项目组都以把这坨东西从项目中去掉为荣”

::...
免责声明:
当前网页内容, 由 大妈 ZoomQuiet 使用工具: ScrapBook :: Firefox Extension 人工从互联网中收集并分享;
内容版权归原作者所有;
本人对内容的有效性/合法性不承担任何强制性责任.
若有不妥, 欢迎评注提醒:

或是邮件反馈可也:
askdama[AT]googlegroups.com


点击注册~> 获得 100$ 体验券: DigitalOcean Referral Badge

订阅 substack 体验古早写作:


关注公众号, 持续获得相关各种嗯哼:
zoomquiet


自怼圈/年度番新

DU22.4
关于 ~ DebugUself with DAMA ;-)
粤ICP备18025058号-1
公安备案号: 44049002000656 ...::