【转】Web前端开发：为何选择MVVM而非MVC
在Web中充斥着所谓的MVC框架，而在我看来，因为一些关键性的技术原因，MVC在Web前端开发中根本无法使用(对的，是无法，而不是不该)
在Web中充斥着所谓的MVC框架，而在我看来，因为一些关键性的技术原因，MVC在Web前端开发中根本无法使用(对的，是无法，而不是不该) 。
在MVC原始报告中指出：
view永远不会知道用户输入，比如鼠标操作和按键。
很显然，在Web前端，你无法做到这一点，因为Web的程序中，用户的输入必须通过监听窗口、文档和元素上的事件来获得。——而这些东西常常被认为是View。
于是一些奇怪的认识诞生了，比如认为Controller应该是View操作Model的中介。
我曾经尝试设计一个编程模型让所有的事件流经Controller，但是事实上我发现这样的做法非常糟糕。——这个尝试让我从MVC转向了MVVM。
John Gossman（WPF的架构师）在他的文章中提到，
Model/View/ViewModel中的View表示可见元素，按钮，窗体，图形或者GUI中更复杂的控件，它会对快捷键进行编码，并且控件自身会管理跟输入设备的交互——这在MVC中本该是Controller负责的（现代GUI环境中发生在Controller上的事情是很长的题外话……我倾向于认为它只是隐藏到后台了，它仍然存在，但是我们不需要像是1979年那样考虑那么多事情了）
MVC这样的结构的正确性在于，任何界面都需要面对一个用户，而Controller “是用户和系统之间的链接”。在经典MVC中，Controller要做的事情多数是派发用户输入给不同的View，并且在必要的时候从View中获取Editor来更改Model，而Web以及绝大多数现在的UI系统中，Controller的职责已经被系统实现了。下面的图片说明了这样的演进过程：
总而言之，对于MVC
- 为1979年的SmallTalk设计
- 界面和程序都由同一种语言编写
- 用户输入完全由程序编写者来处理
- View是单纯用于显示
对于MVVM
- 为2005年的WPF设计
- 界面多使用标记语言，程序则使用编程语言
- 用户输入经过UI系统底层处理和分发，多数以事件的形式被用户程序所知
- View具有独立性，能够管理部分用户输入并且自行反应（它们常常被称作控件，而非视图）
作为一个Web开发者，在二者之间做出何种选择是显而易见的。
最新文章
- 解决UC浏览器或微信浏览器上flex兼容问题
- [常见问题]Project facet Java versin 1.8 is not support.
- 模块module
- Activity的task相关 详解
- nova --debug image-list
- iOS5.1下emoji表情显示方框的解决办法
- LeetCode 90. Subsets II （子集合之二）
- C# readonly与const区别
- [TensorFlow]Tensor维度理解
- 事件代理on
- 009_关闭linux的THP
- i2c状态机方法设计-verilog
- Samba简介与配置(匿名&本地用户验证)
- prop和attr的比较
- 基本功 | Litho的使用及原理剖析
- Asp.Net Core Docker镜像更新系统从wheezy改为stretch
- Android--Led_Demo_APK控制LED灯
- 【BZOJ4140】共点圆加强版（二进制分组）
- 经典Dialog插件Layer
- 纯css3简单实用的checkbox复选框和radio单选框
热门文章
- IDEA中添加类的创建者信息
- 关于yum的一些安装问题
- jquery修改ajax的header的字段origin方法，均被浏览器拒绝
- Hadoop+Spark+Hbase部署整合篇
- TestNG简单的学习-TestNG运行
- docker实战——在测试中使用Docker
- docker集群——搭建Mesos+Zookeeper+Marathon的Docker管理平台
- 手游产品经理初探（四）从Buybutton谈玩家付费
- import * as obj from 'xx'
- 你要相信你所做的一切对一个更美好的世界 Do have faith in what you are doing All for a better world