資訊專欄INFORMATION COLUMN
摘要：老實(shí)說(shuō)我不是第一次想歪了而且很慢總是不能很快抓住要點(diǎn)當(dāng)別人用后端從做博客做論壇聯(lián)系完成的應(yīng)用的時(shí)候我跑去學(xué)單頁(yè)面應(yīng)用還很久掙扎在的思路當(dāng)中我想說(shuō)的是走大多數(shù)人走的路的確是可以減少浪費(fèi)的時(shí)間和錯(cuò)誤的走少數(shù)人在的路當(dāng)然也刺激的我最近才明白原來(lái)前
老實(shí)說(shuō)我不是第一次想歪了, 而且很慢, 總是不能很快抓住要點(diǎn).
當(dāng)別人用后端 MVC 從做博客做論壇, 聯(lián)系完成 MVC 的應(yīng)用的時(shí)候
我跑去學(xué)單頁(yè)面應(yīng)用, 還很久掙扎在 jQuery 的思路當(dāng)中
我想說(shuō)的是, 走大多數(shù)人走的路的確是可以減少浪費(fèi)的時(shí)間和錯(cuò)誤的
走少數(shù)人在的路, 當(dāng)然也刺激的..
我最近才明白, 原來(lái)前端用 MVC 的思路, 和后端 MVC 基本還是一致的
而且, 后端通過(guò)拆分模塊來(lái)降低復(fù)雜度的手段, 還是非?；A(chǔ)實(shí)用的
熟悉后端框架大概理解 Backbone 容易得多, 至少在模型和 View 的關(guān)系上
下面是我最近開(kāi)發(fā)思考和遭遇到的(不能說(shuō)完善, 但比之前清晰不少了):
服務(wù)端渲染的應(yīng)用, 前端原先是只有簡(jiǎn)單的 DOM 操作, 什么都沒(méi)有
然而單頁(yè)面應(yīng)用本地將緩存大部分界面需要的數(shù)據(jù),
而且, 這些數(shù)據(jù)在 Backbone 或者 MVVM 框架都是以 Model 形態(tài)存在的
因此, 所有內(nèi)容都應(yīng)當(dāng)圍繞 Model 中的數(shù)據(jù)進(jìn)行設(shè)計(jì)
我說(shuō)的是 View, jQuery 時(shí)期, 從 DOM 判斷 DOM 狀態(tài)作什么做什么很常見(jiàn)
但是在單頁(yè)面應(yīng)用當(dāng)中, DOM 上的數(shù)據(jù)很容易成為邏輯混亂的來(lái)源
如果 DOM 上有數(shù)據(jù), 就意味著代碼中存在兩份數(shù)據(jù), 就需要進(jìn)行狀態(tài)維護(hù),
而狀態(tài)維護(hù), 特別是手工維護(hù)狀態(tài)的時(shí)候, 非常脆弱
Model 和 View 之間的操作圍繞兩種, 一種更新 View, 一種更新 Model,
注意, 兩種操作如果被混雜在一個(gè)方法里調(diào)用, 將會(huì)埋下隱患,
我指的是 Backbone, 其中 Controller 混在 View 的方法里, 很容易寫(xiě)混
而 MVVM 之類框架明顯自動(dòng)刷新, 不會(huì)遇到這個(gè)問(wèn)題
View 不能存儲(chǔ)數(shù)據(jù)時(shí), Model 里就要盡量存儲(chǔ)全部數(shù)據(jù)了
MVVM 里有 ViewModel 的概念, View 的全部數(shù)據(jù)都是存在 ViewModel 里的
其實(shí) Backbone 的 Model 相對(duì)數(shù)據(jù)庫(kù)蠻像 ViewModel 的,
一些界面用到但是不會(huì)存在數(shù)據(jù)庫(kù)的數(shù)據(jù), 綁在 Backbone Model 上很正常的
以前沒(méi)有注意到這點(diǎn), 但是最近慢慢就有這樣的想法, 包括 Flux 加深了這樣的思路
不說(shuō)前端, 比如后端, 后端的數(shù)據(jù)庫(kù)就可以看做是共享的, 所有代碼都容易訪問(wèn)的
然后, 應(yīng)用被拆分成各個(gè) View, 每個(gè) View 當(dāng)中完成一塊獨(dú)立的工作
注意, 就是依靠這樣, 拆分 View, 全局又只有一份數(shù)據(jù), 應(yīng)用的復(fù)雜度被拆開(kāi)了"
Backbone 雖然分開(kāi)了各種 Collection 和 Model, 其實(shí)很可能會(huì)被一起用
因?yàn)闃I(yè)務(wù)邏輯就是多個(gè)數(shù)據(jù)之間如何關(guān)聯(lián), 有如何相互發(fā)生更改
前端已經(jīng)扮演了一部分服務(wù)端的數(shù)據(jù)處理的功能, 很大程度上服務(wù)端是為備份和同步
就像是 MVVM 雙向綁定 View 和 Model, Meteor 綁定前后端的數(shù)據(jù)來(lái)加快開(kāi)發(fā)
有個(gè)比較容易發(fā)生誤解的是, 并不是寫(xiě)代碼應(yīng)該越寫(xiě)越少來(lái)提升整潔
而是在解決一個(gè)問(wèn)題時(shí), 盡量控制住代碼的量, 避免處亂混亂,
這樣的代價(jià)可能是, 因?yàn)楸徊鹆硕鄠€(gè)子問(wèn)題, 加上另外的問(wèn)題, 代碼總體可能更多
但這個(gè)多出的量很可能因?yàn)榇a進(jìn)行了封裝更清晰了,
而且, 如果是在另一個(gè)文件中, 只有在那個(gè)文件清晰, 問(wèn)題也不大了
有時(shí)候想要架構(gòu)干凈像是一種潔癖, 自己都不清楚會(huì)不會(huì)苛求過(guò)了頭
這邊的重點(diǎn)應(yīng)該是, 怎么寫(xiě), 犯錯(cuò)的機(jī)會(huì)比較少?
因?yàn)殚_(kāi)發(fā)當(dāng)中, 可能別人會(huì)參與進(jìn)來(lái), 也可能某天工作累了忘掉事情,
因此代碼細(xì)節(jié)處理上應(yīng)該減少古怪的地方, 這些地方往往容易出差錯(cuò)
清晰的另一個(gè)好處是編輯起來(lái)更快. 這個(gè)很容易理解.
單頁(yè)面開(kāi)發(fā)當(dāng)中, 除了樣式, 交互的細(xì)節(jié)要考慮還是不少的
想要提升開(kāi)發(fā)效率, 能改變的地方很少, 代碼能直觀盡量直觀了
甚至有的地方, 清晰的代碼其實(shí)只要拷貝到另一邊編輯一下就好了
有條件的話, 用縮進(jìn)語(yǔ)法減少敲鍵盤(pán)次數(shù)更保險(xiǎn), 因?yàn)檫@不干擾代碼邏輯
我因?yàn)?Angular 風(fēng)格難接受, 是從 Ractive 和 Vue 開(kāi)始用雙向綁定的
用了 Vue 以后, 開(kāi)發(fā)變快了, 同時(shí)對(duì)架構(gòu)的理解跟著框架清晰起來(lái)
這中間, 我一直在用 Backbone 寫(xiě)代碼, 對(duì)于 Backbone 的理解也清晰起來(lái)
兩者對(duì)比, 我發(fā)現(xiàn) Backbone 渲染頁(yè)面的繁瑣會(huì)影響我開(kāi)發(fā)的速度,
比較煩的是, 因?yàn)轭l繁使用 DOM 操作, 我對(duì)界面的理解很難像 MVVM 那樣清晰
我得到的結(jié)論是這種編碼速度的減弱能直接影響到對(duì)代碼的理解
抽象能力一直是編程極為重要的手段, 滲透在方方面面
特別是圖形界面的編程, 目前重復(fù)的行為偏多, 特別需要能夠抽象
當(dāng)然, 這個(gè)很難, 用 Backbone 好處是足夠靈活能借助 jQuery 解決各種問(wèn)題,
而當(dāng)我們想要借助比如說(shuō) MVVM 進(jìn)一步抽象, 沒(méi)準(zhǔn)先要克服哪邊新的問(wèn)題
最近有個(gè)消息是 Chrome 36 將 ship Object.observe API 了
解決掉這個(gè)問(wèn)題的話, Backbone 復(fù)雜的 Model 也許能簡(jiǎn)化
雖然其他瀏覽器還沒(méi)看到支持的樣子, 可是雙向綁定的觀念應(yīng)該會(huì)推得更廣
關(guān)于路由, 我開(kāi)始想錯(cuò)了, 我還想, Backbone 的路由能不能有子路由呢?
因?yàn)?View 發(fā)生嵌套時(shí), 路由嵌套, 這種形態(tài)就跟 Sub View 相似了
結(jié)果到處理代碼時(shí), 子路由總是搞不定, 或許又是因?yàn)?Backbone 已經(jīng)設(shè)定了場(chǎng)景
沒(méi)想清楚, 但是將路由和 Model 一樣放全局的確清晰一些了
另外有個(gè)問(wèn)題, 首先, 路由更改時(shí)如果只是 trigger 子視圖渲染這不難
但是路由另一個(gè)功能是, 頁(yè)面打開(kāi)時(shí), 路由需要指揮 View 完成整個(gè)渲染
這個(gè)功能處理起來(lái)和前邊的 trigger 視圖重繪又不一樣
特別是兩個(gè)應(yīng)該一致.. 代碼寫(xiě)起來(lái)就想不到清晰的處理方案了...
看了 Facebook 關(guān)于 Flux 的視頻以后我覺(jué)得更清晰了
雖然我們用的是雙向的綁定, 但是用單向的綁定去理解更清晰
View 固然是根據(jù) Model 渲染的, 但是 Model 并不是跟著 View 更新而改變
View 的更新會(huì)成為事件, 被用戶代碼捕捉, 然后再去操作數(shù)據(jù),
然后, 數(shù)據(jù)的改變觸發(fā) View 完成界面的更新.. 這個(gè)流程非常清晰
View 的更改自動(dòng)更新回到 Model, 但是這里其實(shí)是 ViewModel
為了保存數(shù)據(jù)到服務(wù)器, ViewModel 的數(shù)據(jù)在編輯完成還是要往服務(wù)器發(fā)送的
目前這個(gè)發(fā)送步驟還是少不了, 因此雙向綁定意義不是那么大
當(dāng)然, 視圖自動(dòng)更新這一點(diǎn)的帶來(lái)的好處是非常非常大的
還有, MVC 這里說(shuō)的流程可都沒(méi)把 Router 放進(jìn)去說(shuō)的..
Router 相當(dāng)于保存了整個(gè)狀態(tài)的一個(gè) snapshot, 提供一個(gè)入口
這個(gè)入口要求代碼能自由從指定界面啟動(dòng).. 這個(gè)功能實(shí)現(xiàn)起來(lái)就不輕松
不過(guò)也好在 router 某種程度上類似 Model 中的數(shù)據(jù), 問(wèn)題還是樂(lè)觀的
返回博客首頁(yè): http://blog.tiye.me/
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://www.ezyhdfw.cn/yun/78147.html
摘要：為什么要學(xué)習(xí)數(shù)據(jù)結(jié)構(gòu)語(yǔ)言是相通的人們常說(shuō)，編程語(yǔ)言是相通的，掌握一門(mén)，其他語(yǔ)言很容易就能掌握。其實(shí)，真正想通的不是語(yǔ)言，而是數(shù)據(jù)結(jié)構(gòu)與算法。 為什么要學(xué)習(xí)數(shù)據(jù)結(jié)構(gòu) 1.語(yǔ)言是相通的 人們常說(shuō)，編程語(yǔ)言是相通的，掌握一門(mén)，其他語(yǔ)言很容易就能掌握。個(gè)人認(rèn)為這是一個(gè)似是而非的觀點(diǎn)，每門(mén)編程語(yǔ)言都離不開(kāi)變量，數(shù)組，循環(huán)，條件判斷這些概念，這似乎能支持上面的觀點(diǎn)，但是每門(mén)編程語(yǔ)言都有自己的使用范...
摘要：為什么要學(xué)習(xí)數(shù)據(jù)結(jié)構(gòu)語(yǔ)言是相通的人們常說(shuō)，編程語(yǔ)言是相通的，掌握一門(mén)，其他語(yǔ)言很容易就能掌握。其實(shí)，真正想通的不是語(yǔ)言，而是數(shù)據(jù)結(jié)構(gòu)與算法。 為什么要學(xué)習(xí)數(shù)據(jù)結(jié)構(gòu) 1.語(yǔ)言是相通的 人們常說(shuō)，編程語(yǔ)言是相通的，掌握一門(mén)，其他語(yǔ)言很容易就能掌握。個(gè)人認(rèn)為這是一個(gè)似是而非的觀點(diǎn)，每門(mén)編程語(yǔ)言都離不開(kāi)變量，數(shù)組，循環(huán)，條件判斷這些概念，這似乎能支持上面的觀點(diǎn)，但是每門(mén)編程語(yǔ)言都有自己的使用范...
摘要：我們繼續(xù)看代碼的意思是這個(gè)是一段內(nèi)嵌匯編代碼。也就是在語(yǔ)言中使用匯編代碼。就是匯編版的比較并交換。就是保證在多線程情況下，不阻塞線程的填充和消費(fèi)。微觀上看匯編的是實(shí)現(xiàn)操作系統(tǒng)級(jí)別的原子操作的基石。 原文地址：https://www.xilidou.com/2018/02/01/java-cas/ CAS 是現(xiàn)代操作系統(tǒng)，解決并發(fā)問(wèn)題的一個(gè)重要手段，最近在看 eureka 的源碼的時(shí)候。...
摘要：本筆記共四篇源碼閱讀筆記源碼閱讀筆記源碼閱讀筆記服務(wù)器啟動(dòng)與請(qǐng)求處理源碼閱讀筆記對(duì)象起因前兩天閱讀了的基礎(chǔ)，和中間件的基礎(chǔ)。的前端樂(lè)園原文鏈接源碼閱讀筆記服務(wù)器啟動(dòng)與請(qǐng)求處理 本筆記共四篇Koa源碼閱讀筆記(1) -- coKoa源碼閱讀筆記(2) -- composeKoa源碼閱讀筆記(3) -- 服務(wù)器の啟動(dòng)與請(qǐng)求處理Koa源碼閱讀筆記(4) -- ctx對(duì)象 起因 前兩天閱讀了K...
摘要：什么是維基百科上說(shuō)，全稱，未有中文譯文。其主要功能在于交互式地瀏覽和修改數(shù)據(jù)，生成動(dòng)態(tài)內(nèi)容。從維基百科中可以看到，一般使用的是協(xié)議。響應(yīng)內(nèi)容動(dòng)態(tài)生成，通常取決于客戶端的請(qǐng)求服務(wù)器將響應(yīng)返回給客戶端。 最近在看教程的時(shí)候，又看到了servlet這個(gè)詞，突然發(fā)現(xiàn)我好像并不了解他，只是‘有所耳聞’。所以決定學(xué)習(xí)一下。 什么是servlet 維基百科上說(shuō)： Servlet（Server Ap...
閱讀 2964·2021-11-24 09:39
閱讀 4582·2021-10-27 14:19
閱讀 2155·2021-08-12 13:25
閱讀 2404·2019-08-29 17:07
閱讀 1191·2019-08-29 13:44
閱讀 1184·2019-08-26 12:17
閱讀 537·2019-08-23 17:16
閱讀 2130·2019-08-23 16:46
