老实说我不是第一次想歪了, 而且很慢, 老是不能很快捉住要点.
当他人用后端 MVC 从做博客做论坛, 联络完成 MVC 的运用的时刻
我跑去学单页面运用, 还良久挣扎在 jQuery 的思绪当中
我想说的是, 走大多数人走的路确实是可以削减糟蹋的时候和毛病的
走少数人在的路, 固然也刺激的..
我近来才邃晓, 本来前端用 MVC 的思绪, 和后端 MVC 基本照样一致的
而且, 后端经由过程拆分模块来下降庞杂度的手腕, 照样异常基本有用的
熟习后端框架也许明白 Backbone 轻易很多, 至少在模子和 View 的关系上
下面是我近来开辟思索和遭碰到的(不能说完美, 但比之前清晰不少了):
Model 是运用的中心
服务端衬着的运用, 前端原先是只需简朴的 DOM 操纵, 什么都没有
然则单页面运用当地将缓存大部分界面须要的数据,
而且, 这些数据在 Backbone 也许 MVVM 框架都是以 Model 形状存在的
因而, 一切内容都应当缭绕 Model 中的数据举行设想
我说的是 View, jQuery 时代, 从 DOM 推断 DOM 状况作什么做什么很罕见
然则在单页面运用当中, DOM 上的数据很轻易成为逻辑杂沓的泉源
假如 DOM 上有数据, 就意味着代码中存在两份数据, 就须要举行状况保护,
而状况保护, 迥殊是手工保护状况的时刻, 异常软弱
Model 和 View 之间的操纵缭绕两种, 一种更新 View, 一种更新 Model,
注重, 两种操纵假如被混淆在一个要领里挪用, 将会埋下隐患,
我指的是 Backbone, 个中 Controller 混在 View 的要领里, 很轻易写混
而 MVVM 之类框架显著自动革新, 不会碰到这个题目
View 不能存储数据时, Model 里就要只管存储悉数数据了
MVVM 里有 ViewModel 的观点, View 的悉数数据都是存在 ViewModel 里的
实在 Backbone 的 Model 相对数据库蛮像 ViewModel 的,
一些界面用到然则不会存在数据库的数据, 绑在 Backbone Model 上很正常的
同享 Model, 拆分 View
之前没有注重到这点, 然则近来逐步就有如许的主意, 包含 Flux 加深了如许的思绪
不说前端, 比方后端, 后端的数据库就可以看作是同享的, 一切代码都轻易接见的
然后, 运用被拆分红各个 View, 每一个 View 当中完成一块自力的事变
注重, 就是依托如许, 拆分 View, 全局又只需一份数据, 运用的庞杂度被拆开了’
Backbone 虽然分开了种种 Collection 和 Model, 实在极可以会被一升引
由于营业逻辑就是多个数据之间怎样关联, 有怎样互相发作变动
前端已扮演了一部分服务端的数据处置惩罚的功用, 很大程度上服务端是为备份和同步
就像是 MVVM 双向绑定 View 和 Model, Meteor 绑定前后端的数据来加速开辟
有个比较轻易发作误会的是, 并非写代码应当越写越少来提拔整齐
而是在处置惩罚一个题目时, 只管控制住代码的量, 防止处乱杂沓,
如许的价值多是, 由于被拆了多个子题目, 加上别的的题目, 代码整体可以更多
但这个多出的量极可以由于代码举行了封装更清晰了,
而且, 假如是在另一个文件中, 只需在谁人文件清晰, 题目也不大了
架构只管简朴清晰
有时刻想要架构清洁像是一种洁癖, 本身都不清晰会不会苛求过了头
这边的重点应当是, 怎样写, 出错的时机比较少?
由于开辟当中, 可以他人会介入进来, 也可以某天事变累了忘记事变,
因而代码细节处置惩罚上应当削减离奇的处所, 这些处所每每轻易出差错
清晰的另一个优点是编辑起来更快. 这个很轻易明白.
单页面开辟当中, 除了款式, 交互的细节要斟酌照样不少的
想要提拔开辟效力, 能转变的处所很少, 代码能直观只管直观了
以至有的处所, 清晰的代码实在只需拷贝到另一边编辑一下就好了
有条件的话, 用缩进语法削减敲键盘次数更保险, 由于这不滋扰代码逻辑
开辟工具的效力带来观点的转变
我由于 Angular 作风难接收, 是从 Ractive 和 Vue 最先用双向绑定的
用了 Vue 今后, 开辟变快了, 同时对架构的明白随着框架清晰起来
这中心, 我一向在用 Backbone 写代码, 关于 Backbone 的明白也清晰起来
二者对照, 我发明 Backbone 衬着页面的烦琐会影响我开辟的速率,
比较烦的是, 由于频仍运用 DOM 操纵, 我对界面的明白很难像 MVVM 那样清晰
我获得的结论是这类编码速率的削弱能直接影响到对代码的明白
笼统才能一向是编程极为重要的手腕, 渗入在各个方面
迥殊是图形界面的编程, 现在反复的行动偏多, 迥殊须要可以笼统
固然, 这个很难, 用 Backbone 优点是充足天真能借助 jQuery 处置惩罚种种题目,
而当我们想要借助比方说 MVVM 进一步笼统, 没准先要战胜哪边新的题目
近来有个音讯是 Chrome 36 将 ship Object.observe API 了
处置惩罚掉这个题目的话, Backbone 庞杂的 Model 也许能简化
虽然其他浏览器还没看到支撑的模样, 但是双向绑定的看法应当会推得更广
路由题目
关于路由, 我最先想错了, 我还想, Backbone 的路由能不能有子路由呢?
由于 View 发作嵌套时, 路由嵌套, 这类形状就跟 Sub View 相似了
效果到处置惩罚代码时, 子路由老是搞不定, 也许又是由于 Backbone 已设定了场景
没想清晰, 然则将路由和 Model 一样放全局确实清晰一些了
别的有个题目, 起首, 路由变动时假如只是 trigger 子视图衬着这不难
然则路由另一个功用是, 页面翻开时, 路由须要批示 View 完成全部衬着
这个功用处置惩罚起来和前边的 trigger 视图重绘又不一样
迥殊是两个应当一致.. 代码写起来就想不到清晰的处置惩罚计划了…
Web 运用的生命周期
看了 Facebook 关于 Flux 的视频今后我以为更清晰了
虽然我们用的是双向的绑定, 然则用单向的绑定去明白更清晰
View 固然是依据 Model 衬着的, 然则 Model 并非随着 View 更新而转变
View 的更新会成为事宜, 被用户代码捕获, 然后再去操纵数据,
然后, 数据的转变触发 View 完成界面的更新.. 这个流程异常清晰
View 的变动自动更新回到 Model, 然则这里实际上是 ViewModel
为了保留数据到服务器, ViewModel 的数据在编辑完成照样要往服务器发送的
现在这个发送步骤照样少不了, 因而双向绑定意义不是那么大
固然, 视图自动更新这一点的带来的优点是异常异常大的
另有, MVC 这里说的流程可都没把 Router 放进去说的..
Router 相当于保留了全部状况的一个 snapshot, 供应一个进口
这个进口请求代码能自在从指定界面启动.. 这个功用完成起来就不轻松
不过也幸亏 router 某种程度上相似 Model 中的数据, 题目照样乐观的
返回博客首页: http://blog.tiye.me/
