List&T&和ObservableCollection&T&的相互转化
我的图书馆
List&T&和ObservableCollection&T&的相互转化
1602人阅读
在WPF ， silverlight ，WP7中经常会用到List&T&和ObservableCollection&T&。这里简单讲一下他们之间的相互转换。
1.List&T&的简单介绍：
　List&T&代表的是强类型的Ojbect集合，可以通过索引访问并且提供了查找、排序以及操作此集合的方法。List基本上和ArrayList相同，它用数组的方式实现了接口IList并且他的大小可以根据需要来自动增加。
　List&T&的缺点
　在使用ASP.NET开发时，我们简单的使用DataSource和DataBind来绑定数据，但是在SilverLight中就没有那么简单了。在ASP.NET中，绑定操作只是单向的。绑定操作一旦完成如果再想改变值的话，你必须得弹出一个已经赋值需要修改的对话框或者直接在表单上修改，最后再调用方法DataBind，这样的操作特别的麻烦。
&2.ObservableCollection的介绍：
　ObservableCollection是动态数据集合并且当集合中新增、修改或者删除项目时，或者集合被刷新时，都有通知机制(通过实现接口INotifyCollectionChanged)。
　ObservableCollection的缺点
　当集合中的属性中改变时没有提供任何的通知机制。在程序运行的过程中，通过新增、删除或者改变ObservableCollection集合中的数据时，只有新增和删除数据时，UI集合(DataGrid)中的数据才改变。 但是在修改集合中已经存在的数据时UI层的数据却不能改变。 & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &&
3.这里不得不提一下子INotifyPropertyChanged，它不是集合，只是一个接口。在类中提供一个事件PropertyChanged，当属性的值发生改变时通知客户端。如果对象的状态发生改变时(新增、修改、删除)将触发事件PropertyChange指向那些已经发生改变的集合。 & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &
&&ObservableCollection能通知他变化了也正是因为它实现了INotifyPropertyChanged接口。只是微软给出了具体的实现,如果要写List需要自己实现 INotifyPropertyChanged接口,
说了这么多，言归正传，对于它们互换:T tList = new List(tObjectStruct .ToList()); &ObservableCollection&tObjectStruct& = new ObservableCollection(tList); &&都在构造函数中即可完成也可以:tList.ForEach(p =& tObjectStruct.Add(t));&
TA的最新馆藏
喜欢该文的人也喜欢为啥我要牺牲陪老婆孩子的时间来替你省学英语的时间？&br&&br&---&br&&br&没想到这个答案居然这么多赞，这真不是段子... 借此机会啰嗦一些吧：&br&&br&1. 英语好好学，这是为你自己好。英语是如今当程序员的必备技能，“英语不好也能成为好程序员” 是自欺欺人，不要为自己的懒惰找借口，更不要把这种责任转嫁到别人身上。&br&&br&2. 开源项目，不管人多人少，总是精力有限的。翻译是个体力活，不要想当然地觉得作者顺手翻译一下工作量不大... 你连看英文都嫌麻烦呢，你的麻烦就是麻烦，我的麻烦就不是麻烦了？感情我已经免费提供了一个框架还得劳心劳力把您伺候周到了才算是有责任感... 用开源项目的时候，请千万不要有这种错把自己当客户的想法。觉得缺了什么的话，先想想自己能不能出一份力，而不是作者能为我再做些什么。事无巨细地同步多语言文档，对于项目的核心开发者而言，绝对是一个高投入低回报的行为，所以绝大部分开源项目都只有英文文档。Vue 的中文、日文文档也都是由社区成员主导和维护的。对于社区成员来说，参与翻译一来锻炼英语，二来加深理解，三来可以作为自己的开源贡献资历，其实好处很多。&br&&br&3. 评论里有人说我原始答案的态度让人失望，请别搞错了：我对于为了自己方便理直气壮地向开源项目索求更多的人从来都是这种态度，但这不代表我对所有用户都是这种态度。另外，我最讨厌的就是那种在别人微博/回答下面教别人注意说话口气，说什么取关/粉转路人的人，你要转路人就转，不用特意让我知道。
为啥我要牺牲陪老婆孩子的时间来替你省学英语的时间？ --- 没想到这个答案居然这么多赞，这真不是段子... 借此机会啰嗦一些吧： 1. 英语好好学，这是为你自己好。英语是如今当程序员的必备技能，“英语不好也能成为好程序员” 是自欺欺人，不要为自己的懒惰…
&p&从刚正面的角度来说，&a href=&/p/& class=&internal&&我已经把大漠穷秋第一篇文章里的技术事实谬误都一一指出了&/a&，他的整篇文章从头到尾没有一个点是站得住脚的。后几篇都是人身攻击，没有回应的兴趣。&/p&&p&顺便容我指出一个事实：大漠穷秋的这一系列文章是&b&恶意攻击&/b&，已经不属于争论的范畴了。单纯的技术争论我是敞开了欢迎的，但请别玩下三路的东西。&/p&&p&如果我写了一篇评论别人框架的文章，首先我不会用这么 low 的语言去攻击别人，其次如果里面有事实错误，那我肯定会道歉。如果大漠在看过我的反驳文章之后至少对他自己文章里那些和事实不符的地方道歉，那我也敬他是条汉子。但是他的选择是无视我的回应，在恶意攻击的路上越走越远。到这里我已经发现这个人根本没有沟通的意向 —— 你打脸对面装作没发生，继续自说自话，这还怎么『争论』？&/p&&p&如果他只是个野生 Angular 爱好者，这事儿也就到此结束了，拉黑就是了。但是大漠穷秋是顶着 Angular PM 的招牌，官方指派来推广 Angular 的，现在他做的这些事情，完全就是在给 Angular 招黑... 说真的，我是看不下去了才告诉 Igor 好让他管管，这是为 Angular 好，我跟 Angular 又没有仇，故意放着让他继续代表 Angular 那才是真小人。&/p&&p&有人说『凡是把技术问题上升到政治问题就是不对 / 以后技术讨论不高兴了就告诉你领导』的，我问你们两个问题：&/p&&p&1. 大漠穷秋这样的行为还算是在讨论技术么？如果你觉得大漠穷秋的言论属于合理的技术讨论，我只能报以呵呵然后拉黑你。&/p&&p&2. 如果你是他老板，他顶着你公司的名头来这么一出，你是希望早点有人知会你呢，还是后知后觉不可收拾了才得知？&/p&&p&还有一些上蹿下跳说我推广 Vue 是靠喷别的框架的人，造谣成本真是低啊，说着说着就像真的一样了，有本事你倒是拿具体的例子来啊。&/p&
从刚正面的角度来说，，他的整篇文章从头到尾没有一个点是站得住脚的。后几篇都是人身攻击，没有回应的兴趣。顺便容我指出一个事实：大漠穷秋的这一系列文章是恶意攻击，已经不属于争论的范畴了。单…
谢谢邀请，这个问题我要认真回答一下，尽量不带主观偏向。&br&&br&我们学一个东西，通常两个目的：&br&&br&- 为了解决现有的问题&br&- 为了解决将来可能会有的问题&br&&br&所以，在学这些东西之前，先必须了解，它们是用来解决什么问题的。&br&&br&Angular，React，Vue，这三者其实面对的是同一个领域，那就是Web应用，什么是Web应用呢，我之前有一篇大致讲了：&a href=&///?target=https%3A///xufei/blog/issues/5& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&构建单页Web应用 · Issue #5 · xufei/blog · GitHub&i class=&icon-external&&&/i&&/a&&br&&br&这三者中，Angular的适用领域相对窄一些，React可以拓展到服务端，移动端Native部分，而Vue因为比较轻量，还能用于业务场景非常轻的页面中。&br&&br&在Web应用中，我们需要解决的问题可以归纳为三类：&br&&br&- 状态&br&- 组织&br&- 效率&br&&br&1. 状态&br&&br&什么是&b&&u&状态&/u&&/b&？&br&&br&在一个业务界面中，我们可能会根据某些数据去生成一块界面，然后通过界面上的某些操作，改变一些数据，从而影响界面的另外一些部分。&br&&br&这里面就存在两种关系，一种是从数据到界面，一种是从界面到数据。能够描述界面当前状况的数据，就可以被称为状态。&br&&br&如果不对状态作抽象，很可能会导致逻辑的混乱，比如说，一个地方点了，要改多个地方，这种代码直接写，很容易写乱的，所以，不同的框架采用不同的方式进行了处理。&br&&br&比如说MVVM流的Angular和Vue，还有Avalon，Regular，Knockout，都是走的这一流派，通过类似模板的语法，描述界面状态与数据的绑定关系，然后通过内部转换，把这个结构建立起来，当界面发生变化的时候，按照配置规则去更新相应的数据，然后，再根据配置好的规则去，从数据更新界面状态。&br&&br&React走的是另外一个流派，就是所谓的函数式，在这个里面，推崇的是单向数据流：给定原始界面（或数据），施加一个变化，就能推导出另外一个状态（界面或者数据的更新）。&br&&br&在这里需要额外提一下ReactiveJS，它的理念又有所不同，是基于Reactive的。&br&&br&2. 组织&br&&br&刚才这些，都可以看作是满足最基本的需求，那就是业务的正确性。在这之后，就有另外的诉求了，首当其冲的就是整个业务代码的组织。&br&&br&所谓&u&&b&组织&/b&&/u&，指的是两个方面，一方面是模块关系，另一方面是业务模型。&br&&br&我们是怎样解决模块关系的呢？共识就是组件化。整个应用形成倒置的组件树，每个组件提供对外接口，然后内部只关注自己的实现。这些东西说起来简单，但实际做的时候还是有非常多需要考虑的东西，包括组件的定义，约束，管理，测试等等，而在Web这个体系中，组件化也有一些不太适合的场景，需要做一些权衡，这方面详细说就比较复杂了，需要好多篇幅才能说清楚，可以看看我这篇：&a href=&///?target=https%3A///xufei/blog/issues/22& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Web应用组件化的权衡 · Issue #22 · xufei/blog · GitHub&i class=&icon-external&&&/i&&/a&&br&&br&那么，业务模型又是指什么呢？我们提到React的时候，就会听到Flux，Redux之类的东西，为什么又要有它们呢？我们必须认识到，脱离了这类东西，纯上层的组件化是不牢固的，如果你感受不到，只有一个原因：你的项目的业务层太薄。&br&&br&业务模型指的是所处领域中的业务数据、规则、流程的集合。即使抛开所有展示层，这一层也是应当要能够运作起来的。&br&&br&那么，这跟Redux之类又有什么关系呢？&br&&br&我们刚才提到组件化，整个应用形成了一个组件树，组件之间可能会需要通讯，它们通讯的内容可能是简单的界面事件，也可能是业务含义较深，能够牵一发而动全身的。界面是怎么来的？是由初始界面加上状态形成的，为了能够反映界面的变化，我们必须使得对业务模型的每一个扰动都收敛到确切的状态，所以，这也就是Redux这类东西的意义所在。&br&&br&所以，没有Redux之类辅助方案的React，是不完整的。而Redux本身，也不是局限到只能作为React辅助方案的，它的理念，对于Angular，Vue，照样是非常重要的补充。在同一业务场景下，对于每个框架来说，数据模型层面临的问题都是一样的，在这一层并没有任何分别。&br&&br&另外，Angular 2中引入了RxJS，这个东西处理这方面也是有很大优势的。&br&&br&在这里我要插一句自己的想法，很多学习能力较强的朋友，当他发现FP，FRP之类编程模型的时候，会非常喜欢，但对于大型项目，需要很多人协作的状况来说，不一定是好事。&br&&br&用面向过程，面向对象的那些方式，虽然笨重，但好处是门槛低，符合大多数人的理解和思维方式，并且可以复用几十年积累的各种设计模式和经验。所以，如果不是小而精悍的团队，我对引入FP和FRP都是比较保守的。&br&&br&在这些东西下层，还有Relay，GraphQL等等致力于业务模型同步的方案，但这个引入代价同样是非常大。&br&&br&再插另外一句：很多人吐槽Angular大而全笨重，吐槽React全家桶，但其实世界上大部分人是没有框架整合能力的，小而美的库最后整合了，在面临各种业务需求之后不断引入新模块，也还是一个大而全的方案。在绝大部分场景下，还是有一整套标配模块比较好。你看ExtJS他也单独提供ExtCore模块，但不但竞争不过jQuery，连mootools和prototype都竞争不过，用它的人几乎都是用全方案的。&br&&br&3. 效率&br&&br&效率也分两种，一种是开发效率，一种是运行效率。&br&&br&我们前面提到，组件化，这是提升开发效率的一种手段，在组件化这个点上，各路框架的组织方式大同小异，反正最终都是组件树。&br&&br&具体到单个组件的实现上，我个人是倾向于MVVM流的，之前 &a data-hash=&790dccce26904cdcd11b0fad3bac37b7& href=&///people/790dccce26904cdcd11b0fad3bac37b7& class=&member_mention& data-tip=&p$b$790dccce26904cdcd11b0fad3bac37b7& data-hovercard=&p$b$790dccce26904cdcd11b0fad3bac37b7&&@题叶&/a&
做过对比，MVVM系的代码量会少一些，开发效率稍高一点。&br&&br&其中，Angular因为实现的特殊性，有作用域继承之类的双刃剑黑魔法，开发效率的不稳定因素要高不少，深刻理解的人用起来效率很高，不理解的用了到处是坑。&br&&br&再看运行效率，这里面，Angular是较低的那个，主要在于数据变更检测方式，但这也不是绝对的，在部分场景下，脏检测未必就没有优势，这个记得 &a data-hash=&f7f6a8faef3b8bedb53e7& href=&///people/f7f6a8faef3b8bedb53e7& class=&member_mention& data-tip=&p$b$f7f6a8faef3b8bedb53e7& data-hovercard=&p$b$f7f6a8faef3b8bedb53e7&&@郑海波&/a&论述过。&br&&br&运行效率的另外一面主要是创建和修改DOM，在创建上，大家是没有太大差异的，而在修改DOM的时候，React首创的虚拟DOM有很大优势，所以其他框架内部实现也在逐渐借鉴。&br&&br&（我之前有个对虚拟DOM的回答是有偏差的，稍后去更新）&br&&br&========&br&&br&如果看到这里，很可能你会疑惑，题目问的明明是学哪个好，我说这些是什么意思？&br&&br&我用这些篇幅说明了Web应用的业务开发中存在哪些麻烦，每种技术又是来解决什么痛点的，这样，你可以按照自己的需求去，结合业务场景进行分析，然后选择需要的挨个学下去。&br&&br&其实学API之类的很快，还是要把自己业务中的难点想清楚，带着问题去学，带着需求去学，学思想重于学使用，一定能事半功倍。
谢谢邀请，这个问题我要认真回答一下，尽量不带主观偏向。 我们学一个东西，通常两个目的： - 为了解决现有的问题 - 为了解决将来可能会有的问题 所以，在学这些东西之前，先必须了解，它们是用来解决什么问题的。 Angular，React，Vue，这三者其实面对的是…
&p&呵呵，伸手党的要求真是越来越高了，开源不好做啊。&/p&&p&我觉得吧，这本质上是个情商问题。如果题主是真心想学，那就好好提问： “我觉得文档中 render 函数的部分理解起来有些吃力，希望能有人帮忙解惑”，保证会得到完全不同的结果。然而你却选择了发泄你的负面情绪，把一切责任推给了文档。&/p&&p&善意的提问，我自然会善意地回答。但我也不是圣人，抱怨发泄性质的提问，我忍不住了就要怼的。对这种态度报以善意，只会让伸手党觉得自己理所应当是大爷，社区的环境只会更差。&/p&&p&---&/p&&p&给一些吃瓜群众的补充：Vue 的文档很可能是所有前端项目里最用心的，比较过就知道。看到这个问题的感受大概就跟你辛辛苦苦加班做完了项目，PM 一脸嫌弃地跟你说『怎么才做了这么点功能』差不多。我跟各位贡献者辛辛苦苦写 + 翻译的文档免费给人看，还要被人抱怨，不好意思这个锅我们不背。&/p&
呵呵，伸手党的要求真是越来越高了，开源不好做啊。我觉得吧，这本质上是个情商问题。如果题主是真心想学，那就好好提问： “我觉得文档中 render 函数的部分理解起来有些吃力，希望能有人帮忙解惑”，保证会得到完全不同的结果。然而你却选择了发泄你的负…
&img src=&/v2-d302fcebdfef_b.png& data-rawwidth=&1536& data-rawheight=&2048& class=&origin_image zh-lightbox-thumb& width=&1536& data-original=&/v2-d302fcebdfef_r.png&&&br&&br&&img src=&/v2-81a28ead0b59edd590398e_b.jpg& data-rawwidth=&800& data-rawheight=&1067& class=&origin_image zh-lightbox-thumb& width=&800& data-original=&/v2-81a28ead0b59edd590398e_r.jpg&&&br&&p&项目地址： &a href=&///?target=https%3A///Jianru-Lin/lambda-view& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&lambda-view: A New Tool for Reading JavaScript Code in 2017&i class=&icon-external&&&/i&&/a&&/p&&p&在线 DEMO：&a href=&///?target=http%3A//demo./lv.html%3Fid%3Da46ab6a4b6b86478& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&demo./lv&/span&&span class=&invisible&&.html?id=a46ab6a4b6b86478&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&/p&&br&&p&&b&这是一个为了阅读复杂 JavaScript 代码而开发的工具，以阅读 Vue.js 为例，在 Sublime Text 中打开后感觉非常复杂，不知道该从哪里读起：&/b&&/p&&p&&img src=&&a href=&///?target=https%3A///7d747eb646fd5cc237c7f943df453781_b.png& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/7d747eb6&/span&&span class=&invisible&&46fd5cc237c7f943df453781_b.png&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&& data-rawwidth=&2784& data-rawheight=&1642& class=&content_image& width=&2784& data-original=&&a href=&///?target=https%3A///7d747eb646fd5cc237c7f943df453781_r.png& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/7d747eb6&/span&&span class=&invisible&&46fd5cc237c7f943df453781_r.png&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&&&/p&&br&&p&&b&使用 lambda-view 打开后，可以看到源代码整体的轮廓其实就是一个立即调用的匿名函数：
展开函数部分，值得注意的缩进风格与 Sublime Text 之类的编辑器完全不同，更易读；并且内部结构默认处于收缩状态，可以比较清楚的看到整个函数内的轮廓：
点击后可以继续展开：
不仅可以阅读 Vue.js 之类的前端代码，Node.js 代码也完全没问题。下面的截图来自 Node.js v4.5.0 源代码中的 node.js 文件，可以清晰的看到其整体结构也是一个立即调用的匿名函数：
展开后内部结构很清楚：
对于最新版本的 Node.js v6.5.0 （使用了 ES6 语法）也完全没问题，可以放心实验。该工具的安装使用方法参见项目主页：&a href=&///?target=https%3A///Jianru-Lin/lambda-view& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/Jianru-Lin/l&/span&&span class=&invisible&&ambda-view&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
（截止日，最新版本为 v4.7.0，修复了全部已经反馈的故障）
----------------------------------------------------------------------&/b& &/p&&p&&b&下述内容已不再具有意义，保留仅作历史记录
----------------------------------------------------------------------&/b& &b&
（λ-VIEW 目前已经更新到 3.0 ，本文回答的内容已经不符合目前的情况了，稍后我会做同步的更新，指明新版本的操作方法）&/b&&/p&&p&这个问题是我自己问的，因为这一点困扰了我很久。但是这个月初的时候，我抽了一些时间写了这个工具。它能够将复杂的 JavaScript 代码简化到极易阅读的程度。具体的原理和细节我在后面解释，我们先看看使用体验——&/p&&p&&img src=&&a href=&///?target=https%3A///8ab994db2ad02ebeeefe_b.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/8ab994db&/span&&span class=&invisible&&2ad02ebeeefe_b.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&& data-rawwidth=&1663& data-rawheight=&931& class=&content_image& width=&1663& data-original=&&a href=&///?target=https%3A///8ab994db2ad02ebeeefe_r.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/8ab994db&/span&&span class=&invisible&&2ad02ebeeefe_r.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&&&/p&&br&&p&上图是原始的 AngularJS 源码，可以看到左侧的行号已经超过 2 万行，直接阅读这样的代码无异于&b&划着独木舟在大海里寻找孤岛&/b&，其难度可想而知。不过当我们对其进行处理后（点击上方的 After 按钮），情况就不同了，如下图所示：&/p&&p&&img src=&&a href=&///?target=https%3A///d147c0a90b16ba5c7e2e6_b.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/d147c0a9&/span&&span class=&invisible&&0b16ba5c7e2e6_b.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&& data-rawwidth=&1663& data-rawheight=&931& class=&content_image& width=&1663& data-original=&&a href=&///?target=https%3A///d147c0a90b16ba5c7e2e6_r.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/d147c0a9&/span&&span class=&invisible&&0b16ba5c7e2e6_r.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&&&/p&&br&&p&诶？2 万行代码怎么只剩下两行了？仔细一看，哦，原来这才是 AngularJS 的「真容」！整个 AngularJS 只是由一个立即调用的匿名函数（这里用 {λ} 表示），以及一行额外的处理代码组成。通常我们阅读代码的原则是——&b&先从最外层轮廓上对代码本身获得一个直观的认识，然后再深入到具体的细节里，&/b&这能从根本上避免在刚开始就陷入细节的泥潭。这个工具正是建立在这一原则之上的。或者说，它可以帮助你更好的贯彻这一原则。（我们在稍后会用它来和其他常见的 IDE、文本编辑器进行对比，这会让你对此看得更清楚）&/p&&p&现在我想看看 AngularJS 中的那个匿名函数里到底做了些什么。于是我点击
{λ} 部分，紧接着就变成了下面的样子：&/p&&p&&img src=&&a href=&///?target=https%3A///4a7000a04bfede4ab6eb4b36_b.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/4a7000a0&/span&&span class=&invisible&&4bfede4ab6eb4b36_b.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&& data-rawwidth=&1663& data-rawheight=&931& class=&content_image& width=&1663& data-original=&&a href=&///?target=https%3A///4a7000a04bfede4ab6eb4b36_r.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/4a7000a0&/span&&span class=&invisible&&4bfede4ab6eb4b36_r.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&&&/p&&br&&p&你会注意到：&/p&&ol&&li&顶部标识出了当前函数的路径 &Program& / λ-0 （&Program& 代表顶级作用域，而 λ-0 是我们目前所处于的位置，它是顶级作用域下的第 0 号匿名函数）&/li&&li&左侧列举出了当前作用域内定义的子函数&/li&&li&右侧的源代码区域出现的&b&不是&/b&原始的 JavaScript 代码，而是经过美化的——花括号都不见了，而是改为使用缩进；分号都去除了；等等&/li&&/ol&&br&&p&今天先写到这里，后续会补上&/p&&p&待续1：这个工具是怎么实现的？
待续2：和 IDE 相比这个工具有什么优缺点？
待续3：后续会增加什么功能？&/p&&p&我强烈建议你亲自上 &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&喵德利&i class=&icon-external&&&/i&&/a& （我已经部署好了） 试一试，因为有些细节如果由我在此描述难免太冗长，但你一旦自己亲身体验，就会立刻体会到。&/p&&p&&i& 更新&/i&&/p&&p&&b&这个工具是怎么实现的？&/b&&/p&&p&这个工具看起来很复杂。这可能会产生出让人钦佩的误解。事实上我确实做了一些工作，但并不像看起来那么艰巨。如果列举一下，整个工作实际上是由以下部分合力完成的：&/p&&ol&&li&ACE 编辑器，提供了代码编辑支持&/li&&li&Esprima 解析器，能够将 JavaScript 源代码解析为 AST（抽象语法树）&/li&&li&jQuery 库，帮助我便捷的进行 DOM 操作&/li&&li&Bootstrap 库，简化了界面布局和组织的工作&/li&&li&我自己的代码，实现了最终的功能&/li&&/ol&&br&&p&可见我确实做了一些事。但更主要的工作还是由 1-4 的部分完成的。如果你觉得这个软件很不错，或许上述库的作者们更应当被感谢。&/p&&p&特别值得一提的是 Esprima，它是这整个软件所用到的核心部件。我首先使用它来完成 AST（抽象语法树）的构建，紧接着，我会遍历这颗 AST 树，然后重新按照我想要的方式生成一颗 DOM 树。这样就完成了一次重渲染，将原始的 JavaScript 代码改写为了更简洁的形式。&/p&&p&当然，在遍历 AST 树的过程中也要做一些简单的分析工作。否则就无法实现将子函数抽取出来这样的操作了。不过这个分析操作实在很简单，也没什么可谈的。后续我会在分析过程上做很多工作，实现更多实用的功能。详细的情况可以参见后续的路线图部分。&/p&&p&&b&和 WebStorm 之类的 IDE 相比有什么优缺点？&/b&&/p&&p&术业有专攻。尽管 WebStorm 之类的 IDE 提供了强大的「编辑」功能。但是从实践的角度来说，这些编辑器在用于阅读代码时还存在诸多不足。&/p&&p&比较典型的一点是，编辑器总是老老实实的把原始的排版格式呈现出来。而实际上我们需要的是更加紧凑、标准、一致、适度简化后的呈现。例如下面的对比图所示：&/p&&p&&img src=&&a href=&///?target=https%3A///c2d5badc689f47c8630c76fe_b.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/c2d5bad6&/span&&span class=&invisible&&f47c8630c76fe_b.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&& data-rawwidth=&535& data-rawheight=&259& class=&content_image& width=&535& data-original=&&a href=&///?target=https%3A///c2d5badc689f47c8630c76fe_r.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/c2d5bad6&/span&&span class=&invisible&&f47c8630c76fe_r.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&&&/p&&br&&br&&p&上图是同一段代码（选自 AngularJS）处理前后的对比。我们可以注意到一些细节：&/p&&ol&&li&分号被移除了&/li&&li&花括号被移除了（改为用缩进来表示层次关系）&/li&&li&行间距被适当增大了，看起来没那么拥挤了&/li&&li&函数调用时，前后括号和参数之间都增加了空白&/li&&li&最重要的是，代码从 6 行变成了 4 行，缩短了&/li&&/ol&&br&&p&任何程序员——任何真正尝试过阅读陌生的大型项目的程序员，应该都能够理解这种形式简化将带来的实际好处。它让你更加专注于代码的逻辑，而不是形式。&/p&&p&我们的代码阅读软件能够理解代码的结构，并能够将其转换为更加简洁的形式，这一点有时候能给我们带来意想不到的帮助——例如阅读在 web 环境下那些被压缩过的代码。下图的代码截取自某站点：&/p&&p&&img src=&&a href=&///?target=https%3A///bf2ec34c2b9b_b.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/&/span&&span class=&invisible&&0e2bf2ec34c2b9b_b.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&& data-rawwidth=&1657& data-rawheight=&343& class=&content_image& width=&1657& data-original=&&a href=&///?target=https%3A///bf2ec34c2b9b_r.jpg& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/&/span&&span class=&invisible&&0e2bf2ec34c2b9b_r.jpg&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&&&/p&&br&&p&这样的代码是经过压缩的——删掉了空格、缩进、换行等字符并改写了变量名等——阅读几乎是不可能的。但有些人却必须要从这样的代码里找出感兴趣的东西，比如大家熟悉的白帽子安全人员。&/p&&p&相对一般的 IDE，专门的代码阅读软件在处理这样的问题上更加得心应手。&/p&&p&综上所述，WebStorm 之类的软件在「编辑」、「项目管理」方面更加强大，但在「阅读」、「分析」方面，专门的代码阅读工具会更加方便。&/p&&p&&b&未来的发展路线图——后续功能开发计划&/b&&/p&&p&（待续）&/p&
项目地址： 在线 DEMO： 这是一个为了阅读复杂 JavaScript 代码而开发的工具，以阅读 Vue.js 为例，在 Sublime Text 中打开后感觉非…
果然还是有这个问题，看来大家对八卦都很感兴趣，那我说一下吧。&br&&br&加入Teambition之前，我对TB原有的技术栈和将要做的改造都是有所考虑的，也是带着明确的技术倾向加入的（TypeScript，RxJS，Vue），这些不是无目的的，因为之前，我就认识曾经在Teambition工作过的寸志、题叶等，对这个场景有过一定程度的思考。&br&&br&Teambition主版本的技术栈是Backbone + JQuery + CoffeeScript，这个组合，从当时来看，可以理解，然而，3年过去了，整个前端领域发生了天翻地覆的变化，大清是肯定要亡了，问题在于两点：&br&&br&&ul&&li&康梁，还是孙黄？&br&&/li&&li&三民主义，还是锤子镰刀？&br&&/li&&/ul&&br&对于一个旧系统的改造，无非两条路：逐步改进；推翻重来。一般来说，逐步改进都是优于推翻重来的，因为赌多大就可能输多大。&br&&br&4月中旬，我入职半个月左右的时候，我逐渐倾向于重新做一套，原因在于两点：&br&&br&第一，原先数据模型层处理得不好，主要是：同步和异步的处理、数据的共享和更新机制，如果要改对，非常困难，而且从底层开始把同步改异步，很可能需要一路往上改到顶。在不换掉老数据层的情况下，有很多遗留问题几乎无法解决。&br&&br&我举个例子，有不少数据都是初始化的时候提前加载好，设置到Collection中，然后之后的所有操作全部同步调用，这样的问题在于，并不是所有数据都立刻需要，但如果你要把这些数据的请求改成用Promise之类做封装，有缓存就立即返回，没缓存就查询，会导致与之相关的所有业务代码都要变成异步的方式。&br&&br&另外，数据模型之间的监听关系也存在缺失，由于Teambition产品交互的特殊性，很多视图要共享一些业务数据，而且是全业务存在WebSocket推送，不把监听关系全部写对的后果是，可能你改了某个地方的数据，原先应当同步的十多个集合里面，漏通知了某些，那些对应的视图就不一致了。&br&&br&第二，Teambition有一个Mobile Web版，数据模型跟PC版是一致的，只是视图和业务逻辑比较简单一些，有机会先重构这个版本，验证完整个流程，然后从小到大反推PC版。这个过程是可以降低一些风险的。甚至，后面可以考虑把小企业用户和大企业用户的版本分开，把这个新版作为其中某一个的基础版本。&br&&br&对于新版数据层的设计，我是有整体思路的，只是部分细节的考虑还不完善，这些事情我跟团队的太狼说了，给他讲了RxJS的事情（最近我和他都写过对这方面的总结），还有我对整个这块东西的考虑，他非常给力，冒着差点不能毕业的风险，在学校拼命写了超多代码，把这个事情搞得比我想象中还要快。大家可以看看这个库的提交记录，感受一下战斗力：&a href=&///?target=https%3A///teambition/teambition-sdk& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&teambition/teambition-sdk&i class=&icon-external&&&/i&&/a&&br&&br&然后，5月份下旬开始，他的这块初步可用，我们就开始做新版Mobile Web，同时帮他踩坑。这个版本是用Vue + TS做的，当时vue-rx这个库还不太行，所以我们都是手动订阅数据流，然后往data里面设置。&br&&br&这段时间整体还是比较顺利的，然而到了6月份，出了个突发状况，原先从简聊回归到Teambition的部分同事对我当时的状况产生了误会，认为我长期把PC版丢着不管，去搞一个没那么重要的小版本，本末倒置，然后他们直接开始用React + Redux改进原先PC版的视图层。&br&&br&这个时候我比较尴尬，因为mobile的事情尚未结束，是丢不下来的，即使这块做完，PC版的发展方向也已经大大偏离我的预期了，这几位同事找我聊过一次，建议我把之前做的东西放弃，改用React + Redux。&br&&br&然后我挺苦闷的，想来想去，觉得这样不能接受，就提出了离职。这件事情并未跟团队中任何人说过，只有上层知道。老板向我询问这两种技术方案的关系，我回答了一句：三民主义和共产主义都能救中国，但两个不能一起上。&br&&br&反复争执对团队肯定是很不利，所以当时我的意思是，既然要我放弃之前做的方案，那不如我彻底离开，再招几个React方向的人进来，全部转换到这条路，也是能行的。但上层觉得这样不好，还是建议我们沟通，让那几位同事放弃他们的方案。这个时候，他们大概写了三周左右时间的代码，某一块功能接近完成的状态。&br&&br&公司上层建议我再沟通一下，可能事情还有转机。当时我的心态已经不一样了，后来想想，还是坚持一下吧。&br&&br&既然要沟通，就要讨论后面事情怎么做，尴尬的是，团队中只有个别人支持Vue，绝大部分人无明显倾向（因为原Teambition的开发人员都是没有接触过React的），部分同事强烈倾向于React，所以很难达成共识，而且当时讨论到一半，我倾向使用Vue，希望Mobile和PC版技术栈一致，得到的指责是不顾大局，只顾自己利益，RxJS也被认为不适用于Teambition应用场景，但我坚持认为它在这个场景下，明显优于Redux。&br&&br&争执不下的时候，太狼提议我们使用Angular2，这个妥协的选择被接受了，不少同事认为，使用大厂的产品会更可靠一些，我也不排斥这个选择，因为RxJS、TypeScript这两个东西在ng2里面更加被深度使用。（大家唯一分歧较小的地方竟然是开发语言的选择，除了个别同事希望用ES6之外，好多人都认同TypeScript，因为Teambition最复杂的还是业务逻辑层，用比较严格的限制还是有很多好处的）&br&&br&后来就开始搞ng2，当时正好有一个企业版新功能，然后就先做它，但做的过程中还是踩到不少坑，比如那个rc5版本的升级，又加回来了ngModule，导致大部分代码都修改了，这个东西我很不认同。&br&&br&另外一个出了挺多问题的东西是zone.js，我们那个功能是要集成在主系统里，所以是先启动主应用，然后再bootstrap ng2的，zone跟外面一些东西有些冲突，后来想办法解决了，然后在不同浏览器上又出现了一些问题，花了挺多时间的。&br&&br&这个部分做完之后，大家开始对ng2也不满意了，所以，最后又变成React技术栈了。不过，到这个时候，大家已经逐步意识到RxJS这套方案的好处了，我们开始那个数据层的库，其实是在做整个应用的全局数据状态管理，视图层状态是从它推导出来的，所以现在又引入了redux-observable来做中间的转换。&br&&br&另外，因为业务的发展，整体重构的可能已经减小了，所以只能局部优化，并且尝试把新版数据层逐步接入。后面一段时间中，最大的难点应该就在这里。&br&&br&在回到React体系之后，我基本上就确定一定会离开了。很多技术方案没有明显好坏的区分，都很优秀，但人是有口味偏好的，长期以来，我一直更认同MVVM框架们，认为在JS这种不纯的体系，一味追求纯函数、无副作用，未必是一个好的选择。在复杂场景下，把业务抽象到Rx管道中，视图层的事情则完全交给轻量MVVM框架，把MVVM框架整个视为一层Virtual DOM，一样会是一个好的解决方案。&br&&br&我认同在数据和业务逻辑层使用FP或者FRP以更好地抽象，并且覆盖全量测试，但在贴近视图这里，还是坚持自己的看法：在MDV（数据驱动视图）的情况下，没有必要对业务视图组件做测试，只需保证数据正确即可。在这一点上，我跟很多团队成员是有分歧的。&br&&br&短短8个月，经历了很多事情，终究选择了离开。正如另外一个回答说的，我不差钱，想离职就离职。一个工作十多年的码农，谈不上有钱，也绝不至于饿死，真那么在意钱，我年初就该去阿里啊。像我这种没有任何物质爱好的人，还是做点让自己开心的事情比较好，到这年纪还在一线搞代码，本身就是对这个职业充满热爱。三年前跟响马哥吃饭，我问他，为什么有nodejs，你还要搞fibjs？他说，技术人员有自己的偏好，写代码还不是为了按照自己喜欢的方式吗？我深以为然。&br&&br&Teambition的这些同事，朝气蓬勃，对技术有着很强的热情，虽然理念未必相同，但也能够从他们身上学到不少东西。我虽然比TB前端团队平均年龄大10岁左右，但我内心也是他们这样的人，我也有我的坚持，一样的心高气傲，不愿放弃自己的棱角。&br&&br&现在，在Teambition前端全面转向React体系的情况下，欢迎喜欢这条技术路线的朋友们加入他们，一起改变世界。&br&&br&-------11.28晚上补充--------&br&&br&今天一天看到这么多评论……，有一些事情大家不要过多猜测，我列这些出来的主要原因是要解释技术选型怎么会这么转换的，其中踩过哪些坑，供同行参考。整个事情，我觉得自己沟通方面的问题比较多，入职之前没有沟通清楚是架构师还是前端leader，入职之后花了很久才勉强搞清楚成员的技能等级，平时跟大家交流看法也不多，了解和熟悉业务的过程也比较慢，整个做事情也一直很tb的节奏有些不太搭。&br&&br&这里面不存在上级授权的问题，应该说上层还是寄予了较多期望，我自己在遇到困难的时候是那种比较闷的人，有不少问题是沟通不顺畅引起的，美玲总结得很好，应该还是因为我不太适合这个岗位，所以很勉强地做下去，对公司、自己、团队成员都有挺多伤害的。&br&&br&（以上言辞如果有不合适的，请联系我修改）
果然还是有这个问题，看来大家对八卦都很感兴趣，那我说一下吧。 加入Teambition之前，我对TB原有的技术栈和将要做的改造都是有所考虑的，也是带着明确的技术倾向加入的（TypeScript，RxJS，Vue），这些不是无目的的，因为之前，我就认识曾经在Teambition工…
更新：&br&1、由饿了么 UED （&a href=&/elemeued& class=&internal&&知乎专栏&/a&）设计的桌面端组件库已经开源，文档：&a href=&///?target=http%3A//element.eleme.io/%23/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Element&i class=&icon-external&&&/i&&/a&，仓库： &a href=&///?target=https%3A///ElemeFE/element& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - ElemeFE/element: Desktop UI elements for Vue.js 2.0&i class=&icon-external&&&/i&&/a&。这套组件库是基于 Vue 2 的，我们也希望大家开始使用 Vue 2，一起来丰富它的生态圈。&br&2、下面提到的移动端组件都被整合进了 &a href=&///?target=http%3A//mint-ui.github.io/%23%21/zh-cn& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Mint UI&i class=&icon-external&&&/i&&/a&，仓库在 &a href=&///?target=https%3A///ElemeFE/mint-ui& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - ElemeFE/mint-ui: Mobile UI elements for vue.js&i class=&icon-external&&&/i&&/a&&br&======= 原答案 =======&br&饿了么。&br&从去年开始，有越来越多的项目在使用 vue。这些项目里面，有桌面端（比如 &a href=&///?target=https%3A//security.ele.me& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&饿了么安全应急响应中心&i class=&icon-external&&&/i&&/a&）也有移动端（比如 &a href=&///?target=https%3A//jobs-mobile.ele.me& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&饿了么招聘&i class=&icon-external&&&/i&&/a&），有面向用户的，也有后台系统。&br&实践方案的话，vue + webpack + vue-router + vue-resource。&br&就我个人而言，vue 的开发体验还是比较愉悦的。首先，文档非常友好，所以上手会比较快。其次，配合 webpack 和 vue-loader，每个页面都是一个 .vue 文件，写起来很方便。另外，适合做组件化开发（每个组件也是一个 .vue 文件，可以全局或者在需要的地方引入），如果遇到比较复杂的、父子组件间需要频繁通信的场景，可以用 vuex 搞定。&br&在写业务的过程中，团队的同事们抽象了很多公共组件出来，开源在 github （&a href=&///?target=https%3A///elemefe& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&饿了么前端 · GitHub&i class=&icon-external&&&/i&&/a&）上，大家有兴趣的话可以去试一试。这里我把这些组件分类介绍一下：&ul&&li&移动端：&/li&&/ul&vue-swipe：&a href=&///?target=https%3A///ElemeFE/vue-swipe& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&swipe&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&幻灯片组件&br&&br&vue-infinite-scroll：&a href=&///?target=https%3A///ElemeFE/vue-infinite-scroll& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&infinite-scroll&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&无限滚动，可以实现向下的无限加载。是一个 directive&br&&br&vue-loadmore：&a href=&///?target=https%3A///ElemeFE/vue-loadmore& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&loadmore&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&下拉加载和上拉加载。是一个 component&br&&br&vue-toast-mobile：&a href=&///?target=https%3A///ElemeFE/vue-toast-mobile& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&toast-mobile&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&toast 组件&br&&br&vue-indicator：&a href=&///?target=https%3A///ElemeFE/vue-indicator& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&indicator&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&indicator 组件，提示用户正在加载，自带 modal&br&&br&vue-msgbox：&a href=&///?target=https%3A///ElemeFE/vue-msgbox& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&msgbox&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&弹出框组件&br&&ul&&li&桌面端&/li&&/ul&目前正在编写一套完整的桌面端组件库，利用它可以快速搭建后台页面。将于近期开源。&br&&br&下面要隆重介绍的是前两天刚发布的一个工具。对于使用 webpack 打包的项目来说，不管是用 vue，angular 还是 react，开启一个新项目的时候都有许多脚手架的工作要做，比如写 webpack 的配置文件，安装依赖等等。这个过程有时会很繁琐，而且对新人不友好。为了解决这个问题，团队的小伙伴写了一个构件工具——&a href=&///?target=http%3A//elemefe.github.io/cooking/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&cooking - 更易上手的前端构建工具&i class=&icon-external&&&/i&&/a&。上面列出的工作，cooking 都可以一键完成，能够极大地解放生产力。而且，它不仅支持 vue，angular 和 react 也是支持的。
更新： 1、由饿了么 UED （）设计的桌面端组件库已经开源，文档：，仓库： 。这套组件库是基于 Vue 2 的，我们也希望大家开始使用 Vue 2，一起来丰富它的生态圈。 2、下面提到…
&blockquote&某些把持话语权的所谓大V&/blockquote&&p&咦，大V是说我吗？说得好像我有能力操控知乎一样，哈，看看最近这些话题下排面前面的答案，我还差点就信了。&/p&&p&至少在知乎上，在较少涉及政治敏感的话题领域，话语权不是靠“把持”能得到的。某些人的习惯就是匿名之后然后空口污蔑，随口就把一个不错的产品和平台说得好像是助纣为虐的帮凶。哦对了，还有一个习惯是开口就定义了“整个前端圈子”，把自己打扮成只身抵抗暴政的模样。嘿，这也入戏太深了吧？&/p&&blockquote&很多想支持一下大漠的人，都必须匿名，想过原因么？&/blockquote&&p&想过。匿名就不用为自己的言辞负责了嘛。&/p&&blockquote&大漠的文章的确有很多错误，因言获罪和政治正确难道就是对的？&/blockquote&&p&犯了错误就要承担后果。都是成年人了，这道理还要人教？&/p&&p&什么“因言获罪”？他是被请喝茶了还是被拘留了？真的“因言获罪”的，是能连累到让所有程序员连JavaScript都打不出来。你们别太狂妄自大了。&/p&&p&什么“政治正确”？一个布道师出来胡口乱喷，坑自己老板、坑自己公司、坑自己社区、最后不出意料也坑了自己，我难道还要说：表演虽然拙劣，但情有可原，都是 vue || angular || google || react || 知乎 || 微博 || 小白 || 大V || 前端圈子 || 社会的错！&/p&&p&&br&&/p&&p&穷秋以这样一种姿态离职并删完所有文章，十之八九是谷歌给的压力，但应该也不会出来道歉了。&/p&&p&其实就算他出来道歉，还是会有一些人出于各种原因给他鸣不平啊。&/p&&p&&br&&/p&&p&但你们考虑过被污蔑“抄袭”的开源库的作者和所有contributors的感受么？辛辛苦苦写代码被人一句抄袭，虽然有点智商的一看都知道是胡扯，但是架不住总有少数匿名的和匿脸的在那儿嗡嗡嗡啊。心情大坏有没有？&/p&&p&你们考虑过无端被骂“小白”的感受么？我只是听说某框架容易上手，就先选这个开始学了，我招谁惹谁了，要被这样羞辱？&/p&&p&你们考虑过Angular社区其他人的感受吗？这种“推广”是唱哪出？大漠穷秋老师是被盗号了？好多人来问我vue是不是真的抄袭了ng，我该怎么回答？还有vue的粉丝骂上门来，怼回去吧，好像失了分寸，不做声吧，又咽不下这口气……&/p&&p&你们考虑过栾跃的感受么？好不容易做到大中华区主管这个位置了，是造了什么孽要出来这样低声下气的道歉？而且道歉之后，下属居然还不停手，继续变本加厉的发攻击帖？这不是打我脸根本领导无能吗？以后在公司还怎么混？&/p&&p&你们考虑过Google人事的感受吗？不解职吧，如此违背公司价值观；解职吧，万一被说是拿临时工顶包怎么办？反正今夏是好不了了。&/p&&p&你们考虑过广大吃瓜前端的感受吗？艹，明明是这后端api测都没测乱写一通，我给他开个工单，他撇下一句，就你们前端娱乐圈事儿多！&/p&&p&&br&&/p&&p&&br&&/p&&p&要之：穷秋攻击因为vue容易上手而选择vue的前端初学者，是为不仁；自己老板出来道歉他还乱发文章，给公司添乱，是为不忠；给Angular社区丢人现眼，对不起辛苦推广ng的社区同仁，是为不义；一篇一篇攻击文章出来，却对别人指出错误不予回应，是为无礼；自己技术水平根本跟尤雨溪不在一个水平上，挑错对手，乱起战端，是为不智；被人吊打，还不承认错误，反过来污人抄袭，无勇且不知耻。如此不仁不忠不义不智无礼无勇无耻，还有甚可洗的？&/p&&p&&br&&/p&&p&&br&&/p&&p&&br&&/p&&p&PS. 对最后这段话可以有两种理解。一个是我腹黑（骂人不带脏字）。一个是，作为跟大漠穷秋有过一面之缘的前辈（我就不谦虚了），给的忠告。采取哪种理解，各自随意。&/p&
某些把持话语权的所谓大V咦，大V是说我吗？说得好像我有能力操控知乎一样，哈，看看最近这些话题下排面前面的答案，我还差点就信了。至少在知乎上，在较少涉及政治敏感的话题领域，话语权不是靠“把持”能得到的。某些人的习惯就是匿名之后然后空口污蔑，随…
先声明，作为 Vue 的作者我有利益相关，但我尽量从客观角度说说我的看法。&br&&br&&b&主流并不一定只有一个赢家&/b&&br&&br&首先，我觉得框架间的竞争并不是零和游戏。虽然解决的核心痛点有重合，但适用场景还是有区别。比如 React/Vue 这样以 view layer 为核心，可以灵活选择整体架构和工具链的框架，和 Angular 2 这样大而全一站到底的框架，各有各适合的场景。Vue 因为不需要构建也能直接用，也能用在一些比 React 更轻量的场景中。撇开场景，也有开发风格的偏好问题。有些人用 React 更有效率，有些人用 Vue 更有效率，而 C#/Java 生态圈一大群人会觉得 TypeScript 和 Angular 2 让他们更有效率。最理想的情况是大家都找到最符合自己场景需求和开发偏好的框架，所以我觉得多框架的并存是合理且有意义的，不太可能出现 Angular 2 火了就没人再用 React/Vue 的情况。&br&&br&&b&技术角度&/b&&br&&br&React 和 Angular 2 都有服务端渲染和原生渲染的功能（Angular 2 只是号称会有，具体啥时候会有，好不好用还不知道）。这两个东西在对此有需求的场景下，是很有吸引力的，但实际上对此有硬需求的场景占多少百分比则是个问题。比如服务端渲染的前提是前端渲染层得用 Node.js 交给『全栈』去做，原生渲染的多端代码复用率会因应用实际需求而变化，制约它们发挥的条件还是不少的，因此我个人乐观地认为这并不会影响 Vue 在整个市场中占有一席之地。另一方面，手淘已经押宝 Weex，也不排除哪天我会搞个 Vue 服务端渲染。&br&&br&性能方面，这里不深入谈了，这几个主流框架都应该可以轻松应付大部分常见场景的性能需求，区别在于可优化性和优化对于开发体验的影响。这一点上我觉得 Vue 可能是最简单的，加好 track-by 就 ok 了。React 需要 shouldComponentUpdate 或者全面 Immutable，Angular 2 需要手动指定 change detection strategy，都有一定程度的侵入性。但是从整体趋势上来说，浏览器和手机还会越变越快，框架本身的渲染性能在整个前端性能优化体系中，会渐渐淡化，更多的优化点还是在构建方式、缓存、图片加载、网络链路、HTTP/2 等方面。顺道说一句，Angular 2 压缩后的大小是 500 多 kb，在移动场景反正我是不敢用。&br&&br&&b&开发体验&/b&&br&&br&这方面，我个人认为 Vue 是最容易上手，最具亲和度的。工具链方面最近刚发布了 vue-cli，1 分钟搞定 webpack 配置。Vue 组件格式只要你会 HTML/CSS/JS 就能写，你要用 coffeescript 或者 less/sass 也没问题。React 的 JSX 是道坎，但跨过去之后会有一定的生产力提升。社区工具丰富，但实在太多，配置工具麻烦。CSS in JS 也不是每个人的菜。Angular 2 目前上手配置也非常麻烦，官方正在写一个 cli，但体验如何要出来了才知道。它推荐的默认语言是 TypeScript，这个对于静态类型爱好者来说是个大优点，配合 WebStorm/VSCode 体验会很不错，但也不是所有人的菜。&br&&br&&b&社区生态&/b&&br&&ul&&li&React 是目前最成熟也最活跃的，但有一个问题就是过于频繁的方案迭代，几个月前的最佳实践可能明天就变过去式了，而 FB 官方对于最佳实践基本是采取让社区自行发展的态度，因此社区长期处于一个百家争鸣的状态，直到今年下半年才慢慢地开始合流到了 React + react-router + redux 的主流方案，并且这两天也开始讨论工具链的最佳实践。这些东西一旦稳定下来，会进一步巩固 React 的地位。&/li&&li&Vue 的社区固然比不上 React，但也不算太小。Gitter 聊天室里有 1300 来号人，国内听说也有几百人的 QQ 群，论坛上也还算有些活跃度。社区组件也在稳步发展：&a href=&///?target=https%3A///vuejs/awesome-vue%23libraries--plugins& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&vuejs/awesome-vue · GitHub&i class=&icon-external&&&/i&&/a& 当然比起 React 来说还是小巫见大巫，希望 2016 能更进一步。比起 React 来说，Vue 的一个好处就是提供了官方推荐的 Vue + vue-router + vuex + webpack + vue-loader 的全套方案，如果你不想三个月换一套，就跟着官方推荐走；如果自己有想法，那就自己整也没问题。&/li&&li&Angular 2 的社区，目前来说基本没有，到现在连文档都没写完呢，也没法有什么生态。更伤的是 ng2 和 ng1 的生态是完全割裂的。2016 年能怎么发展，要看 Google 的社区运营做得如何，但不管怎么说 Google 的影响力在那边，群众基数还是很大的...&/li&&/ul&&br&&b&用户来源&/b&&br&&br&这一块
&a data-hash=&cc0145aee04dd53cc6590edd& href=&///people/cc0145aee04dd53cc6590edd& class=&member_mention& data-editable=&true& data-title=&@徐飞& data-tip=&p$b$cc0145aee04dd53cc6590edd& data-hovercard=&p$b$cc0145aee04dd53cc6590edd&&@徐飞&/a& 老师分析得很具体了。当然了，在中国还有另一个制约条件，那就是 IE8，这三个框架里面只有 React 支持 IE8，所以这应该会对 React 在中国的份额有所帮助... 另外徐飞叔预测 2016 年底 Vue 能和另外两个在同一数量级，我觉得还是太乐观了，我个人觉得不太可能 =_=&br&&br&&b&说在最后&/b&&br&&br&看到有人说这个题是在拍马屁。React/Angular 的作者们都不上知乎，那只能认为是在针对我了，但我是理解不了问问题的人拍我马屁有什么好处... 我知道 Vue 最近在国内被提起的比较多，难免会有人觉得是不是吹太过了，对于有这样的想法的同学我有如下建议：&br&&br&1. 如果你没用过 Vue，去用一用，自然会有你自己的判断；&br&2. 如果你用过 Vue，觉得确实吹过头了，欢迎写文章有理有节地来批评。有批评我才能改进 Vue，我会非常感谢你。&br&3. 如果你用过之后觉得确实不错，欢迎你加入社区贡献一份力量，一起推动项目的发展。
先声明，作为 Vue 的作者我有利益相关，但我尽量从客观角度说说我的看法。 主流并不一定只有一个赢家 首先，我觉得框架间的竞争并不是零和游戏。虽然解决的核心痛点有重合，但适用场景还是有区别。比如 React/Vue 这样以 view layer 为核心，可以灵活选择整…
&p&这是钓鱼贴么？呵呵，楼下果然出现了：&/p&&p&- 答非所问推销自己利益相关框架的&/p&&p&- 明嘲暗讽 Vue 简单所以受众都是低端公司和培训机构的高端咨询师&/p&&p&- 连双向绑定是啥都没搞懂就在说 Vue 不适合大型应用的&/p&&p&- 在评论下面嚼舌根直接给人甚至用户群体扣帽子的&/p&&p&承认 Vue 比其他框架易用易学有那么难么？（注意，我这里回答了问题）&/p&&p&为了避免有些玻璃心的其他框架的用户偏题，重要的话说三遍:&/p&&p&&b&说 Vue 易学易用不等于说其他框架不好&/b&&/p&&p&&b&说 Vue 易学易用不等于说其他框架不好&/b&&/p&&p&&b&说 Vue 易学易用不等于说其他框架不好&/b&&/p&&p&当然有些人还是会特意去搜集材料来怼 Vue，说我吹 Vue 包治百病，欲加之罪何患无辞，爱咋咋地吧。&/p&&p&这两年做个框架真是人性的百态都看遍了，很有意思。&/p&
这是钓鱼贴么？呵呵，楼下果然出现了：- 答非所问推销自己利益相关框架的- 明嘲暗讽 Vue 简单所以受众都是低端公司和培训机构的高端咨询师- 连双向绑定是啥都没搞懂就在说 Vue 不适合大型应用的- 在评论下面嚼舌根直接给人甚至用户群体扣帽子的承认 Vue 比…
&p&我是大自然的搬运工。&/p&&p&这是我在博客园正好写的一篇Blog，希望对你有用：&a href=&///?target=http%3A///indream/p/3602348.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&从Script到Code Blocks、Code Behind到MVC、MVP、MVVM&i class=&icon-external&&&/i&&/a&&/p&&br&&p&=====================（Hi，我是分割线）=====================&/p&&p&刚过去的周五（3-14）例行地主持了技术会议，主题正好是《UI层的设计模式——从Script、Code Behind到MVC、MVP、MVVM》，是前一天晚上才定的，中午花了半小时准备了下就开讲了。&/p&&p&今天看到了&a href=&///?target=http%3A///xueduanyang/p/3601471.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&大家在为MVVM knockout.js友(ji)好(lie)地交流&i class=&icon-external&&&/i&&/a&，所以就整理下然后更扩展地分享。&/p&&p&主要目的也不是为了争论，毕竟只是正巧主题相近，原本的打算也就是一次技术分享并且记录下来。&/p&&p&那么我们就按照大致的历史进程将这些概念进行划分：&/p&&ul&&li&Script&/li&&li&Code Blocks、Code Behind&/li&&li&MVC、MVP、MVVM&/li&&/ul&&p&我们知道的是现实的历史发生顺序并不如上，因为思想都是相似的，比如MVC很早很早就出现了，解释型语言至今基本上也有很多分支而且在互联网时代大行其道。&/p&&p&但我要说的是：&b&不要在意这些细节！&/b&&/p&&p&当然了，这是玩笑，我的意思是，这些内容我懒得应该在另外独立的主题探讨，篇幅也有限。&/p&&br&&br&&ul&&li&&b&&u&Script&/u&&/b&&/li&&/ul&&p&这里脚本的意思不是指当时是用脚本开发，而是像写脚本一样开发。它们都有一个特点：&b&功能单一、管理单一、入口单一&/b&。&/p&&p&我们最早的程序是汇编，当时的码农的工作是兼职，工作内容是编写一套寿命不长的机器控制指令，有些甚至是命令，比如至今依然保留的Command（亮点自寻）：&/p&&br&&img src=&/a06b7aa8ec3f_b.jpg& data-rawwidth=&677& data-rawheight=&522& class=&origin_image zh-lightbox-thumb& width=&677& data-original=&/a06b7aa8ec3f_r.jpg&&&br&&p&到后来计算机被用于科学计算等，需求推动了需要更高的开发效率，所以我们有了高级语言。&/p&&p&那个时候码农其实多是数学家，程序的作用很简单，就是执行一些数学计算，类似今天ICPC的一些算法问题，比如Hello World：&/p&&br&&div class=&highlight&&&pre&&code class=&language-text&&main()
printf(&hello,world\n&);
&/code&&/pre&&/div&&br&&p&这时候，程序还可以被归结为输入到输出的过程，我们还能去讲讲冯诺依曼模型。&/p&&p&在这个时代，开发是指编写机器指令，甚至都不配用“开发”这个词来描述这项工作。&/p&软件、UI和Markup Language&p&在那个时代讲UI等于放屁，根本不存在这种概念。但全赖我们有神器——&b&摩尔定律&/b&。&/p&&p&但我个人认为摩尔定律是不足以让一个敲命令行的时代在几十年间转变成这种各类框架技术架构实践模式的时代，真正推动计算机形成自有的工程学体系的是还有两样东西就是：&/p&&ul&&li&&b&人的能力并没有变强&/b&，至少没有在同级数下变强。&/li&&li&&b&人类一定会物尽其用&/b&&/li&&/ul&&p&因为人的能力并没有“跟上”机器，所以才会出现各种模式、方法、工具等等来补足人的不足，以最大地透支机器性能。就像我前几天在闪存无聊时突然想到的一句： &b&架构是对客观不足的妥协，规范是对主观不足的妥协&/b&。&/p&&p&当我们需要机器做的事情多了起来，我们就没办法在一个芯片上解决所有事情，所以才会有冯诺依曼模型、计算机架构，没办法用一台机器解决，所以才要互联网、分布式、云计算。&/p&&p&同样，随着计算机的发展，&b&要做的事情多了，就出现了软件的概念&/b&。当“开发”正式化，我们需求的软件就变得：&b&功能繁杂、管理统一、多入口&/b&。&/p&&p&&b&真正变化的不是客观本质，而是需求&/b&。就像这里说的“软件入口”在客观上我们还是只有一个，原理上始终都只有一个启动程序、一个启动代码片段。但&b&“软件的入口”，已经从指代Main函数变成了指代起始UI，用户已经从指代专业人士变成了指代一般消费者，先有软件的需求，才有软件的定义，而需求是在变化的&/b&。&/p&&p&一个软件需要比当时多几个数量级的代码：&/p&&ul&&li&客观上我们没办法做一个能显示所有代码的显示器&/li&&li&主观上我们没办法在超快速滚动中看清所有代码&/li&&/ul&&p&&b&所以我们需要添加索引、用多个文件组织代码&/b&。&/p&&p&机器的发展和软件的需求扩大和细化，我们开始出现了用户界面（User Interface）的概念和最适合用于界面的语言——标记语言（Markup Language）。当然，ML不是为UI而生的，它只是十分适合UI，所以才和UI坠入爱河。&/p&&p&&b&因为有了更高UI的需求，所以代码才正式被分化为描述做什么（业务逻辑）和有什么（UI）的两部分，因为我们开发时没办法在两种思维方式下同时工作，开发时的人脑是单线程的&/b&。我们所看到的同时进行UI和逻辑开发只不过是我们学会了在两种模式下快速切换，看起来像同时进行，而不是真正的同时进行。同样的情况也发生在不同的代码片段的开发中。&/p&&p&分化的情况除了UI，还发生在方方面面，比如数据操作、UI的对象和样式分离，我们还是继续从UI讲下去吧。&/p&&br&&br&&ul&&li&&b&&u&Code Block和Code Behind（其实还有Code Inside，比如onclick=&javascript:alert('哎呀我*')&）&/u&&/b&&/li&&/ul&&p&&b&UI和逻辑分开了两种语言来写，但是它们也要放在同一个项目中，因为它们原本就是要一起工作的。&/b&即使是分开，也需要相连，因为这是它们本来要解决的问题。&/p&&p&这时候我们出现的（通常的）解决方案就是Code Block和Code Behind。虽然从时间上似乎Code Block比Code Behind要早，有种感觉就是越新越好，但实质上它们正交替地发展着，因为&b&谁也没办法解决UI和逻辑代码分化后的一个哲学问题——UI和逻辑是一起的，但是它们却不是一起的&/b&。&/p&&p&Code Block能很好地处理UI和逻辑间在一起的关系，你在同一个地方可以同时维护UI和逻辑：&/p&&br&&br&&div class=&highlight&&&pre&&code class=&language-text&& 1 @model GM.OA.Finance2.Web.Models.FinancialBase.CurrencyModel
ViewBag.Title = &EditCurrencyDrawer&;
Layout = &~/Views/Shared/_DrawerLayout.cshtml&;
7 @section styles {
&link href=&/Content/base/table-form.css& rel=&stylesheet& /&
&link href=&/Content/base/drawer.bigtitle.css& rel=&stylesheet& /&
&/code&&/pre&&/div&&br&&br&&br&&br&&div class=&highlight&&&pre&&code class=&language-text&&&a href=&#& class=&addcurrency oa-btn& oa-style=&green&&添加新币别&/a&
&script type=&text/javascript&&
$(document).ready(function () {
$('.addcurrency').click(function () {
$.oa.drawer.openUrl('AddCurrencyDrawer/', 'addcurrency', {
width: 300
&/code&&/pre&&/div&&br&&br&&p&Code Behind能很好地处理UI和逻辑各自分开的关系，你可以让UI和逻辑各自做好各自的事情：&/p&&br&&div class=&highlight&&&pre&&code class=&language-text&&&asp:Button ID=&RemoveSelectedCurrency_Button& runat=&server& Text=&删除选中币别& OnClick=&RemoveSelectedCurrency_Button_Click& /&
&asp:Button ID=&RemoveAllCurrencies_Button& runat=&server& Text=&删除所有币别& OnClick=&RemoveAllCurrencies_Button_Click& /&
&/code&&/pre&&/div&&br&&br&&div class=&highlight&&&pre&&code class=&language-text&& 1 protected void RemoveSelectedCurrency_Button_Click(object sender, EventArgs e)
var currencyId = Currencies_ListBox.SelectedItem.V
currencyManager.Remove(currencyId);
protected void RemoveAllCurrencies_Button_Click(object sender, EventArgs e)
currencyManager.RemoveAll();
&/code&&/pre&&/div&&br&&br&&p&&b&因为存在两种实现方式，所以就存在了对比，因为存在了对比，所以就存在了争论&/b&。就像是Java和.NET、PHP和.NET、WebForm和MVC、Mac OS和Windows、iOS和Android、腾讯和所有其他互联网公司，等等。&/p&&p&问题不在哪个更好，而是我们要解决什么问题。当然，这听(ben)着(lai)像(jiu)是客气话了。&/p&&p&真正在UI和逻辑分化后带来的实质问题是：&/p&&ul&&li&&b&是按逻辑和UI划分地管理，还是按单界面的事务进行划分地管理&/b&&/li&&/ul&&p&至少UI和逻辑刚分化的时代，在软件上，我们还认为同一项事务是基于同一个UI的一系列操作完成的。&/p&&p&在摩尔定律还持续发挥作用的时候，计算机领域依旧高速发展，所以&b&通常我们还在为一样事物争论、思考、辩证的时候，它已经发生了质变了，不变的只是我们要解决的问题&/b&。&/p&&br&&br&&ul&&li&&b&&u&事务，以及界面、数据、事件、业务&/u&&/b&&/li&&/ul&&p&在之前说到过了，&b&当需求变得庞大，解决方案也会变得庞大；当解决方案变得庞大，就会出现细分；当出现细分，就会出现按哪种方式管理的问题&/b&。&/p&&p&&b&软件从处理一件事务发展到了要处理许多事务&/b&，各事务间有包含、顺序、主次等等的关系，变得越来越复杂。因为数据与逻辑庞大了，所以数据与逻辑就分离了，然后事件和业务分离了。&/p&&p&&b&它们的关系已经在我们还理得清之前持续发展而变得更加难理得清&/b&，但在一个时间点上，它们UI的领域大致分化成这些原子：&/p&&ul&&li&界面&/li&&li&数据&/li&&li&事件&/li&&li&业务&/li&&/ul&&p&你要细化的话会有更多繁杂的细节，但相信这么写的话争议性比较小。&/p&&p&&b&当一个问题出现一次的时候它是一个问题，当一个问题出现了无数次的时候它会成为历史，当一个问题将会出现无数次的时候，它将需要一个明确的定义和解决方案。&/b&&/p&&p&其中，&b&数据的更新和界面的更新这一特殊事件的问题被放大了无数倍，因为它出现了无数次&/b&。&/p&&br&&br&&br&&ul&&li&&b&&u&Model-View-Controller&/u&&/b&&/li&&/ul&&p&在ASP还在奋斗的时候WebForm突然到来，正如WebForm还在奋斗的时候MVC突然到来。当然，&b&我这里讲的MVC还是最原始的MVC，因为MVC在我们还在争论的时候已经发展了许多不同分支了&/b&。&/p&&p&有一点相信大家同意的就是，&b&我们今天讨论争论的MVC、MVP、MVVM、Code Behind等等都源自于职能分化和规划的思想与目的，MVC不是它们的开始，但是一个很好的开始&/b&。&/p&&p&相信MVC的模型大家很熟悉，也很容易找到，我们这里用一下某百科的图：&/p&&img src=&/a1c71efe626f7affc1bec2be6600b67f_b.jpg& data-rawwidth=&512& data-rawheight=&353& class=&origin_image zh-lightbox-thumb& width=&512& data-original=&/a1c71efe626f7affc1bec2be6600b67f_r.jpg&&&p&我们可以看到的是，界面被分到了View，数据分到了载体Model上由Model“携带”，业务集中在Controller中，而推动业务的事件由用户与View交互，通过View向Controller发动。&/p&&p&当然，实现由很多种，每种细节上都有不同，所以我才只讲也只能讲大致的MVC。&b&MVC的其中一个缺点便是没有明确的定义，所以不同的实现（比如Struts和&a href=&///?target=http%3A//ASP.NET& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&ASP.NET&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& MVC）细节上都是不一样的&/b&。&/p&&p&我们需要知道的是，&b&MVC并不是像上面所说的一些事情那样是一种“必然的”结果，它是一系列必然结果问题中的一种解决方案，而且是不完美的解决方案&/b&。我们顺着推理去到一个地方很容易犯的一个错误就是认为路只有这一条而忽视其他可能性（估计这也是导致很多争斗的原因）。另外，我们在讨论一件事物不完美的时候是有一个情境的，所以请不要像“我说它色彩单一，然后你把它涂成彩色后证明我是错的”。&/p&&p&MVC的一般流程是这样的：&b&View（界面）触发事件--》Controller（业务）处理了业务，然后触发了数据更新--》不知道谁更新了Model的数据--》Model（带着数据）回到了View--》View更新数据&/b&&/p&&p&这里也不多再陈述MVC的原理、实践等等，因为这就太长篇大论了。&/p&&br&&br&&ul&&li&&b&&u&Model-View-Presenter和一些衍生&/u&&/b&&/li&&/ul&&p&像我们之前推理的，&b&分化是一种需求的必然结果，但却没有个一个确定的结果&/b&，比如Code Behind和Code Block的问题等等。&/p&&p&MVC顺着需求把UI相关的工作分化成了三份，这点经过实践证明无可厚非。&b&但是它们的三角关系却被一些人认为带来了一些问题，或者应该说他们有“更好的”解决方案&/b&。&/p&&p&在只有Code Behind和Code Block的那个时候维护是很直接的，不是在同一段代码内解决就是在同一个关联的事件上解决。三角关系的问题就是维护问题。&b&在MVC，当你有变化的时候你需要同时维护三个对象和三个交互，这显然让事情复杂化了&/b&。&/p&&p&我们之前说到，随着摩尔定律，软件的需求不断地变化和变得庞大。&b&随着需求变得庞大的时候，需求变化也变得频繁，这是一个出现了无数次以后也将会出现无数的无数次的一个问题，所以它需要一个解决方案，哪怕它不一定能被解决&/b&。&/p&&p&为了解决需求变化，从《人月神话》到敏捷到DDD，&b&它不是我们已经解决了的问题，而是我们正在解决的问题&/b&。放在UI的模式和MVC上来讲，&b&就是优化或者替代MVC模式&/b&，其中之一就是Model-View-Presenter（MVP）模式。&/p&&p&我们先看看两个MVP模式的图：&/p&&img src=&/1ad9bffd8a988d3be012551_b.jpg& data-rawwidth=&600& data-rawheight=&315& class=&origin_image zh-lightbox-thumb& width=&600& data-original=&/1ad9bffd8a988d3be012551_r.jpg&&&p&（图一）&/p&&img src=&/ffa885b9adc7f4dca8bfec_b.jpg& data-rawwidth=&612& data-rawheight=&393& class=&origin_image zh-lightbox-thumb& width=&612& data-original=&/ffa885b9adc7f4dca8bfec_r.jpg&&&br&&p&（图二）&/p&&p&两幅图是不同的，但是对MVC的改进的思想却是一样的：&b&切断的View和Model的联系，让View只和Presenter（原Controller）交互，减少在需求变化中需要维护的对象的数量&/b&。&/p&&p&这种方式很符合我们的期待，因为我们倾向于：&/p&&ul&&li&&b&用更低的成本解决问题&/b&&/li&&li&&b&用更容易理解的方式解决问题&/b&&/li&&/ul&&p&许多时候并不是一种模式不好，而是因为人没办法执行，比如不容易理解，我们就会选择容易理解的方式。&b&计算机依赖摩尔定律用数量的增长来解决问题，而人是用方式的改变来解决问题的&/b&。同样因为客观原因我们不善于维护多个对象和多个对象之间的关系，所以我们改变了，或者说简化了这种方式。&/p&&p&&b&MVP定义了Presenter和View之间的接口，让一些可以根据已有的接口协议去各自分别独立开发，以此去解决界面需求变化频繁的问题&/b&。上面两图都有接口，不过接口的实现和使用细节不一样，不过思想上是一致的。&/p&&p&在这里要提到的是，事实上，&b&需求变化最频繁的并不一定是最接近用户的界面，但基本可以确定的是，最接近用户的界面是因为需求变化而需要最频繁更改的&/b&。当然，如果View如果是API而不是UI，那就另说了。&/p&&p&还有一些用来“解决”MVC这项缺点的比如有：&a href=&///?target=http%3A//ASP.NET& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&ASP.NET&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& MVC的ViewBag，Cocoa的delegate。它们都为了简化数据更新的问题而存在，包括MVVM。&/p&&br&&br&&ul&&li&&b&&u&Model-View-ViewModel&/u&&/b&&/li&&/ul&&p&先直接看看Model-View-ViewModel（MVVM）的图：&/p&&img src=&/1d9336019baa5cabdf0e5e30b3effffb_b.jpg& data-rawwidth=&715& data-rawheight=&151& class=&origin_image zh-lightbox-thumb& width=&715& data-original=&/1d9336019baa5cabdf0e5e30b3effffb_r.jpg&&&p&从图上看是比MVP简单了，更不用说MVC了。个人不认为MVVM是从MVP进化而来，我只觉得这是在MVP之后出现的一种“更好的”UI模式解决方案，但是用MVP来与之对比比较容易说明问题。&/p&&p&&b&ViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel间没有了MVP的界面接口，而是直接交互，用数据“绑定”的形式让数据更新的事件不需要开发人员手动去编写特殊用例，而是自动地双向同步&/b&。数据绑定你可以认为是Observer模式或者是Publish/Subscribe模式，原理都是为了&b&用一种统一的集中的方式实现频繁需要被实现的数据更新问题&/b&。&/p&&p&&b&比起MVP，MVVM不仅简化了业务与界面的依赖关系，还优化了数据频繁更新的解决方案，甚至可以说提供了一种有效的解决模式&/b&。&/p&&p&至此，我们能理解为什么许多人认为MVVM是最好的一种模式，没有之一。但事实上，&b&MVVM也是依赖于我们至今所讲的“特有的情境”&/b&。&/p&&p&当然，最优雅的也是第一个能作代表的实践就是Windows Presentation Foundation（WPF）了。&/p&&br&&br&&ul&&li&&u&&b&Web&/b&&/u&&/li&&/ul&&p&之上，我们在模式演变的推论基本上都还是基于桌面软件的，但是&b&过去十年却是互联网的时代&/b&。实际上大部分&b&让大家争议的并不是在桌面领域最合适的是那个，而是在Web领域的模式问题，也就是在B/S场景下的问题&/b&。&/p&&p&当软件离开单机，去到网络的时候，因为场景变了，所以原有的解决方案也变了，不过需求依然是不变的。&b&我们依然要解决的问题是用户交互与数据更新的问题，还有维护等等的问题&/b&。&/p&&p&当场景变到Web的时候，我们发现&b&MVVM用来做服务端是极其不适用的，至少现在是不适用的&/b&。而MVP你提都不用提。为什么呢？因为：&/p&&ul&&li&&b&网络资源成本过高&/b&&/li&&li&&b&开发成本过高&/b&&/li&&/ul&&p&问大家一个问题，当一个网页的数据更新后，你希望更新用户看到的数据，你会怎么做？&/p&&p&一般情况下，你会：&/p&&br&&div class=&highlight&&&pre&&code class=&language-text&&window.location.reload();
&/code&&/pre&&/div&&br&&p&就算你不这么做，用户也会：&/p&&br&&div class=&highlight&&&pre&&code class=&language-text&&F5
&/code&&/pre&&/div&&br&&p&就像之前说的，我们会选择更直接的方式解决问题。直接刷新页面的原因是因为这样更直接，更容易解决数据更新的问题。&/p&&p&很多时候&b&你不会愿意为了一个数据更新写一个AJAX，更别说这个AJAX要带来Loading、事件顺序处理、网络问题、异常处理等等，这就是开发成本过高&/b&。&/p&&p&另一个网络成本过高就更容易解释了，虽然宽带是基本包月的，但也不带这么用的，何况还有移动用户。更主要的原因是，&b&在本地软件，更新数据是一个引用问题，而在网络应用上，这是一个传输问题&/b&。传输成本远高于引用成本，引用之上顶多是在本地内存中再进行一次内存拷贝。&/p&&p&这个时候，&b&我们会更倾向于用MVC模式，因为在Web层面，我们更倾向于一次性更新数据&/b&。&/p&&br&&br&&ul&&li&&b&&u&Web的MVVM&/u&&/b&&/li&&/ul&&p&所有问题都不是问题，就算有问题也要解决问题。&/p&&p&为什么这个标题下突然冒出这么一句话？我想说的是，&b&需求依旧是不变的，是推动进步的原动力&/b&。&/p&&p&还有我之前说过，当我们讨论或者争论一个问题的时候，问题的对象已经发生改变了，而且这次是在我们讨论这个问题之前已经发生改变了。&/p&&p&&b&网络资源成本不断下降&/b&，相信已经不需要多提及。摩尔定律和相近的一些原理正在发挥着它应用的作用，网络带宽越来越高、相应速度越来越快。&/p&&p&&b&如果传输因为相对成本下降而导致数据传输的成本低于开发人员拒绝客户的成本，那么它就会被实现而不是被拒绝&/b&。&/p&&p&另外还有一点就是&b&因为技术的进步，技术的资源不断被更大规模地压榨，需求也不断地增长，那么需求始终会增长超过相对不变的开发成本的&/b&。比如jQuery的出现解决了很多问题，我们现在更多地去使用AJAX，哪怕很大一部分依然是为了解决网络资源不足的问题；我们会用更多的样式代码而用了相对更少的图片；我们不再那么依赖Flash一类的矢量图解决方案而直接录制视频。&/p&&p&至少上一节我们说到的两个导致大家选用MVC的问题都正在被解决，所以我们有理由相信未来Web不仅仅需要MVC，可能会需要MVVM或其他解决方案。至少我们能理解容易理解为什么前端会出现一些MVVM的框架，比如先驱knockout.js和AngularJs。这些框架本身的好坏就不作讨论了，因为我们讨论的是模式。&/p&&p&&b&在Web上，MVVM的对比对象就不是MVC，而是Code Block&/b&。&/p&&p&数据即时更新的需求在扩大，但未必有达到一定要用MVVM这一等级的高大上的模式，实际上如果你要更新一个数据，你还是会采取：&/p&&br&&div class=&highlight&&&pre&&code class=&language-text&&$('.notice').html('发送成功！');
&/code&&/pre&&/div&&br&&p&因为......我们依然会采取更直接的方式解决问题......&/p&&p&&b&实际上，现在Web MVVM主要并不是用在了Web或者Wap上，而是移动App上&/b&。按照前面的说法，只可能是：&/p&&ul&&li&HTML+JS比原生在一些场景上更适合Native&/li&&li&在移动App上比Web上更适合使用MVVM&/li&&/ul&&p&哪怕是Native开发，实际上iOS的开发上也是用类似的数据绑定的方式的。这里也不深究了，毕竟我也不算懂iOS。&/p&&p&要说的是，在Web MVVM或者Web的模式上，也就是&b&Web的富应用上，现在还不过是个初期由膨胀的需求推动的阶段&/b&。&b&重要的不是技术会怎么走，而是需求和客观条件会怎么走&/b&。&/p&&p&可能Webform会因为高速开发而焕发第二春，它的AJAX的模式也十分满足于简单开发，但似乎大家需要的不是GUI式的网页。&/p&&br&&br&&ul&&li&&b&&u&结尾语&/u&&/b&&/li&&/ul&&p&我们不一定需要MVVM，但我们一定需要更强大的方式去解决不断膨胀的Web需求。&/p&&p&我们可以预见的是：&/p&&ul&&li&会有更强大的浏览器&/li&&li&会有更强大的JavaScript或者框架&/li&&li&会有更加适合的模式&/li&&/ul&&p&除去客气话的部分，我还是想说，在不同的需求下其实有最适合的解决方案，&b&通常让我们纠结的不是因为哪个解决方案更好，而是我们看到的条件不够多&/b&。&/p&&p&编译语言当然比解释语言效率高，但考虑到开发和维护成本，JavaScript等始终会大行其道，比如Node.JS、Python；.NET和微软当然很强大，移植.NET到其他平台也很容易，但微软是家有自己商业模式和要赚钱的公司；当然有些实践和技术更好，但其他开发人员会避开甚至否定自己不擅长的东西，大家都喜欢确定的东西；有些技术更强大，但是只是基于特殊的客观条件和需求，如果你想做大，要么创造客观条件，要么把它结合需求......&/p&
我是大自然的搬运工。这是我在博客园正好写的一篇Blog，希望对你有用： =====================（Hi，我是分割线）=====================刚过去的周五（3-14）例行地主持了技术会议，主题正好是《UI层的…
我就说一点... Patreon 并不是我唯一的收入来源。我现在赚得比在 Meteor 和 Google 都多。&br&&br&当然了，贵司如果想要买安心，赞助一个也是极好的。&br&&br&---&br&&br&稍微补充点关于切题的。&br&&br&首先，同样是个人项目，稳定度可以天差地别。有些人是玩票，有些人是靠项目吃饭，用『个人项目』一刀切地去评判，显然不合理。这里复制黏贴我很久以前的一个评论：&br&&br&&blockquote&大公司 vs. 个人项目，这个是个常见的担忧。我其实有时候觉得一个项目人多未必就好，你如果去 Vue/React/Angular/Ember 的 GitHub issues 转转，你会发现 Vue 的未关闭 issues/bugs 是最少的，而且开过 issue 的人都知道 Vue 的 bug 通常都会在一两天之内就 fix （对数据感兴趣的可以看看 &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Issue Stats&i class=&icon-external&&&/i&&/a&）。我也参与 Meteor 的维护，深知一个庞大的项目在多人参与之后反而对于 issue 的定位、分配、修正速度有多大的影响，正因为 Vue 是我一个人的项目，我对任意一段代码都了如指掌，所以我修 bug 的效率是多人协作项目根本无法比较的。&br&&br&另一方面，敢不敢依赖个人项目其实完全取决于团队对风险的容忍度，以及觉得项目的开发者靠不靠谱。你看 Laravel / Express / Backbone / Babel / CoffeeScript / Browserify / Webpack / Less / PostCSS / jspm 其实都是一人主导的项目，大家不照样用得风生水起？所以非要拿这个说事儿其实也不全面的。Vue 还很年轻，严格来说我认真开始推 Vue 也就是今年下半年的事情，而且 1.0 发布后的 commit 里面 PR 越来越多，我相信外部贡献者的参与度只会越来越高。&/blockquote&&br&其次，个人 vs. 公司项目，也要看公司的项目在公司的布局中是什么地位。对于大公司来说，开源项目主要是两个意义：&br&&ol&&li&支持自家产品开发；&/li&&li&作为公司的技术公关，提高业界口碑，有利于招人。&/li&&/ol&这其中 (1) 是项目存在的前提，(2) 是开源的目的。很多公司的开源项目是从内部项目开一个分支出来，两边同时维护。如果项目成员忙于应对内部需求，项目开源的部分会立刻变成次要的任务。这一点最近 Dan