老实说我不是第一次想歪了, 而且很慢, 总是不能很快抓住要点.
当别人用后端 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/
