資訊專欄INFORMATION COLUMN
摘要：老實說我不是第一次想歪了而且很慢總是不能很快抓住要點當別人用后端從做博客做論壇聯系完成的應用的時候我跑去學單頁面應用還很久掙扎在的思路當中我想說的是走大多數人走的路的確是可以減少浪費的時間和錯誤的走少數人在的路當然也刺激的我最近才明白原來前
老實說我不是第一次想歪了, 而且很慢, 總是不能很快抓住要點.
當別人用后端 MVC 從做博客做論壇, 聯系完成 MVC 的應用的時候
我跑去學單頁面應用, 還很久掙扎在 jQuery 的思路當中
我想說的是, 走大多數人走的路的確是可以減少浪費的時間和錯誤的
走少數人在的路, 當然也刺激的..
我最近才明白, 原來前端用 MVC 的思路, 和后端 MVC 基本還是一致的
而且, 后端通過拆分模塊來降低復雜度的手段, 還是非常基礎實用的
熟悉后端框架大概理解 Backbone 容易得多, 至少在模型和 View 的關系上
下面是我最近開發思考和遭遇到的(不能說完善, 但比之前清晰不少了):
服務端渲染的應用, 前端原先是只有簡單的 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 上很正常的
以前沒有注意到這點, 但是最近慢慢就有這樣的想法, 包括 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 視圖重繪又不一樣
特別是兩個應該一致.. 代碼寫起來就想不到清晰的處理方案了...
看了 Facebook 關于 Flux 的視頻以后我覺得更清晰了
雖然我們用的是雙向的綁定, 但是用單向的綁定去理解更清晰
View 固然是根據 Model 渲染的, 但是 Model 并不是跟著 View 更新而改變
View 的更新會成為事件, 被用戶代碼捕捉, 然后再去操作數據,
然后, 數據的改變觸發 View 完成界面的更新.. 這個流程非常清晰
View 的更改自動更新回到 Model, 但是這里其實是 ViewModel
為了保存數據到服務器, ViewModel 的數據在編輯完成還是要往服務器發送的
目前這個發送步驟還是少不了, 因此雙向綁定意義不是那么大
當然, 視圖自動更新這一點的帶來的好處是非常非常大的
還有, MVC 這里說的流程可都沒把 Router 放進去說的..
Router 相當于保存了整個狀態的一個 snapshot, 提供一個入口
這個入口要求代碼能自由從指定界面啟動.. 這個功能實現起來就不輕松
不過也好在 router 某種程度上類似 Model 中的數據, 問題還是樂觀的
返回博客首頁: http://blog.tiye.me/
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/78147.html
摘要：我們繼續看代碼的意思是這個是一段內嵌匯編代碼。也就是在語言中使用匯編代碼。就是匯編版的比較并交換。就是保證在多線程情況下，不阻塞線程的填充和消費。微觀上看匯編的是實現操作系統級別的原子操作的基石。 原文地址：https://www.xilidou.com/2018/02/01/java-cas/ CAS 是現代操作系統，解決并發問題的一個重要手段，最近在看 eureka 的源碼的時候。...
摘要：本筆記共四篇源碼閱讀筆記源碼閱讀筆記源碼閱讀筆記服務器啟動與請求處理源碼閱讀筆記對象起因前兩天閱讀了的基礎，和中間件的基礎。的前端樂園原文鏈接源碼閱讀筆記服務器啟動與請求處理 本筆記共四篇Koa源碼閱讀筆記(1) -- coKoa源碼閱讀筆記(2) -- composeKoa源碼閱讀筆記(3) -- 服務器の啟動與請求處理Koa源碼閱讀筆記(4) -- ctx對象 起因 前兩天閱讀了K...
摘要：什么是維基百科上說，全稱，未有中文譯文。其主要功能在于交互式地瀏覽和修改數據，生成動態內容。從維基百科中可以看到，一般使用的是協議。響應內容動態生成，通常取決于客戶端的請求服務器將響應返回給客戶端。 最近在看教程的時候，又看到了servlet這個詞，突然發現我好像并不了解他，只是‘有所耳聞’。所以決定學習一下。 什么是servlet 維基百科上說： Servlet（Server Ap...
閱讀 2830·2021-11-24 09:39
閱讀 4082·2021-10-27 14:19
閱讀 2043·2021-08-12 13:25
閱讀 2334·2019-08-29 17:07
閱讀 1112·2019-08-29 13:44
閱讀 1066·2019-08-26 12:17
閱讀 462·2019-08-23 17:16
閱讀 2048·2019-08-23 16:46
