数据绑定迷思,暨 MVC 与 MVVM 傻傻分不清

之前的制作方式,我在《JavaScript 爱好者开发 Java Web 开发的“心路历程” 》文中有所整理。现在完成项目后,想想有这么几种数据绑定方式:一、服务器端 JSP 生成。读取接口 JSON 数据然后拼凑 HTML,这是方式安利应该是最快的,因为 JSP 和 数据库都在服务器本地。但因为 HTML 和数据的同时生成,用户体验反而较逊于“AJAX”的异步加载。而且需要在远端呈现一个 url。二、JSONP 异步调用。接口也是输出 JSON,所以只使用浏览器 JavaScript 脚本即可以调用数据,无须经过服务端或 JSP 渲染。优点是这样一种异步加载,可快速显示页面,然而通过 JSONP 异步调用数据。这样不仅显示速度较快,而且用户体验较好(先快速显示界面)。页面可不需要服务器支持,仅作为静态文件内嵌在客户端中,有接口便可,但不足就是修过静态页面必须经过客户端升级。于是可以将页面寄存在服务端中。我们的专题就是利用这个模式制作的。

以上两种的基本的数据绑定方式。由此封装的方案有 JSP Tags Files、自定义标签两种,分别是服务端和客户端(广义的客户端)生成的,有可以最终实现比较方便的调用数据。我想到的方式大概有这几种——至于哪一种最好应该没有一概而论。

……

以前总以为 MVVM 是 MVC 的派生,现在读了对岸的博文之后,才知道它们是两回事(对岸的中文解释总是更符合我胃口多些,一说就明白……目下所及,大陆人写的文章,往往不知所云呐……)

首先得強調一點,Knockout根本不是Angular的對手!! 倒不是因為Angular太強大,KO還沒上擂台就被叫去領便當;而是二者定位不同,KO只專注於MVVM,而Angular包含整套MVC。MVVM所聚焦的Data Binding只是MVC中實做View的一環,故二者不該直接相比,就像沒人會拿Office跟iPhone相比一樣道理,要比也是Windows Phone對上iPhone,定位才相近。Angular是完整的MVC架構,真要比較,對手應該是Durandal、Ember或Backbone,而Knockout隸屬Durandal陣營,所以應是Durandal vs Angular,哦哦...

http://blog.darkthread.net/post-2014-06-07-go-to-angularjs.aspx

更进一步说,就是:

兩年前初見Knockout.js後便一腳踏入MVVM世界無法回頭。學習簡單很快上手,用Knockout做出錯誤少又容易擴充維護的AJAX網頁。在此之前,為了讓欄位連動,總要寫一堆<input />、<select> onchage、onclick事件,事後常需要在一堆事件程式碼裡追查更動來源,更糟的是稍一調整就常因觸發順序改變導致錯誤,修改維護是件苦差事;改用KO後,專心把ViewModel邏輯寫好,餘下的欄位連動便能一次到位,加上邏輯都集中寫在ViewModel內,維護起來輕鬆許多。

不過,最近參與SPA專案(Single Page Application,指從頭到尾沒有任何PostBack,停在同一網頁裡完成全部工作的網頁,最經典的例子是Gmail),逐漸感受單靠Knockout(或者該說MVVM)的不足。SPA需在同一網頁切換不同操作介面,當介面複雜度提高,網頁HTML、JavaScript開始龐大交錯,管理及維護難度急速上升。面對這類情境,引用JavaScript端MVC設計模式讓架構分明,簡化維護難度,是較好的選擇,而Knockout只專注於MVVM,仍需要其他MVC架構輔助才容易建構成SPA。

博主似乎更倾向于 NG 多些。不过我受过 ExtJS 的虐之后,对大型的库只敢远观~~

时间: 2024-10-25 00:46:56

数据绑定迷思,暨 MVC 与 MVVM 傻傻分不清的相关文章

杂谈: MVC/MVP/MVVM (二)

MVP MVC的缺点在于并没有区分业务逻辑和业务展示, 这对单元测试很不友好. MVP针对以上缺点做了优化, 它将业务逻辑和业务展示也做了一层隔离, 对应的就变成了MVCP. M和V功能不变, 原来的C现在只负责布局, 而所有的逻辑全都转移到了P层. 对应关系如图所示:   业务场景没有变化, 依然是展示三种数据, 只是三个MVC替换成了三个MVP(图中我只画了Blog模块), UserVC负责配置三个MVP(新建各自的VP, 通过VP建立C, C会负责建立VP之间的绑定关系), 并在合适的时机

一名风险投资人总结的创业者们十大迷思

  我最近成了一名风险投资人,所以经常可以遇到一些创业者[1]在创业时常犯的错误.为了避免一遍又一遍的重复说教,我想把这些错误在这里做一个总结: 迷思一:一个好想法就可以让你赚大钱 事实是好想法对于商业成功既不是充分条件也不是必要条件.微软应该算是获得商业成功的典型,但是在它的整个发家史上却找不到一个完全独创的"好想法".事实上微软正式通过模仿对手的想法并在竞争中打败对手而一步步发展壮大的.Google确实有一些独创的,像Page Rank,Ad-words,廉价机器集群等.但是这些没

数据驱动的迷思

身为一名七年的数据从业者,对一些专业概念尚不能准确的描述.比如什么是大数据?我虽然从2008年开始做这块的东西,但国内到了2011年的时候才兴起了这一概念.我花了三四年的时间,也不能对其有一个准确的把握.就在前天,我把我对大数据的认识拿出来和团队交流时,也产生了多处分歧,甚至有成员提议不要提"大数据"这一名词.可有客户就是被"大数据"这一概念吸引过来的,你绕开这块不讲可不行.同样,对于什么是数据驱动(Data-driven)?我依旧不能给一个准确的描述,这也许是一个

android. mvc,mvp,mvvm架构分析

问题描述 android. mvc,mvp,mvvm架构分析 android现在流行三种架构,mvc,mvp,mvvm网上介绍的文档很多都介绍的比较浅,最重要的是没有完整的比较大的项目结合分析, 解决方案 本质上来说,mvc mvp mvvm是差不多的东西,只是在model,viewmodel和businessmodel的职责划分上略有不同.而且在"完整的比较大的项目",其实根本不能教条使用教科书上的某一种模式."介绍的文档很多都介绍的比较浅"恰恰说明了这一点--把

杂谈: MVC/MVP/MVVM (一)

前言 本文为回答一位朋友关于MVC/MVP/MVVM架构方面的疑问所写,旨在介绍iOS下MVC/MVP/MVVM三种架构的设计思路以及各自的优缺点. MVC MVC的相关概念 MVC最早存在于桌面程序中的, M是指业务数据, V是指用户界面, C则是控制器. 在具体的业务场景中, C作为M和V之间的连接, 负责获取输入的业务数据, 然后将处理后的数据输出到界面上做相应展示, 另外, 在数据有所更新时, C还需要及时提交相应更新到界面展示. 在上述过程中, 因为M和V之间是完全隔离的, 所以在业务

关于数字化转型的五个迷思

你也许对数字化转型是什么略有耳闻,但是数字化又不是什么呢?看看专家如何破除关于数字化业务运营的迷思并解释为什么仅凭IT是做不到的. 如今,IT经理们在数字化他们的机构时感到压力时是情有可原的. 学者,调研公司,甚至是本媒体都在推广这样的想法,就是机构可以大大地改善绩效并战略性地将数字技术应用到机构和运营的过程中,从而开辟崭新的业务范围. 尽管有着铺天盖地的宣传和数十年的IT基础设施的投资,只有很少的公司达到目的. 在196位回应<计算机世界>的2017年技术预测调查报告的IT经理,董事和总裁中

私有云之迷思:未来是什么?

本文讲的是私有云之迷思:未来是什么?,[编者的话]非常好的一篇文章,作者从OpenStack目前的困境讲起,聊到了私有云的产生背景,进而介绍了云计算的发展史.从云计算诞生的初衷以及现在流行的分布式应用又延伸出自己的核心观点:服务器和虚拟机都不会消失,但我们与它们之间直接的互动将会越来越少. 私有云市场日渐式微,但千万不要怪OpenStack.因为从一开始,关于私有云的想法可能就错了. 如同AWS被认为是云端服务标准,VMware被认为是本地服务器虚拟化标准,而OpenStack则被一度誉为是VM

MVC, MVP, MVVM比较以及区别(下)

原文:MVC, MVP, MVVM比较以及区别(下)  上一篇得到大家的关注,非常感谢.一些朋友评论中,希望快点出下一篇.由于自己对于这些模式的理解也是有限,所以这一篇来得迟了一些.对于这些模式的比较,是结合自己的理解,一些地方不一定准确,但是只有亮出自己的观点,才能抛砖引玉不是? 欢迎各位拍砖.:) 阅读目录: 四. MVP模式      4.1 MVP的思想      4.2 UI界面接口化      4.3 Presenter -- Model和View之间的桥梁      4.4 MVP

MVC, MVP, MVVM比较以及区别(上)

原文:MVC, MVP, MVVM比较以及区别(上) MVC, MVP和MVVM都是用来解决界面呈现和逻辑代码分离而出现的模式.以前只是对它们有部分的了解,没有深入的研究过,对于一些里面的概念和区别也是一知半解.现在一边查资料,并结合自己的理解,来谈一下对于这三种模式思想的理解,以及它们的区别.欢迎各位高手拍砖. 阅读目录: 一. MVC, MVP, MVVM诞生的需求? 二. 一段典型的耦合代码 三. MVC模式      3.1 主动MVC      3.2 被动MVC      3.3 W