摘要:數據驅動應該是從這種模式開始流行的。這種其實已經非常趨向與數據驅動了。可以看到數據驅動的難點和關鍵點就是數據結構的設計。數據驅動主要是處理模塊之間的一種邏輯。
數據驅動應該是從flux/redux + react這種模式開始流行的。
他的背后不僅僅是數據驅動這么簡單,在復雜的系統中,我覺得它解決了一個很關鍵的問題就是模塊間的交互/通信。有很多文章拿他和mvc/mvvm去比較,我個人覺得沒有特別的可比性,因為解決的問題不同。
以往處理模式一個稍微復雜點的例子:
假如有這么一個頁面,我們按照以往模式開發,首先模塊化開發,拆分成A,B,C 三個模塊,然后每個模塊有自己的子模塊。
如果需求簡單還比較好解決,每個模塊中自己解決自己的邏輯,解耦的非常清晰。父子之間的關系也非常明確。
例如銷毀C模塊,會自動銷毀它的子模塊C1和C101。
模塊間的關系也很清晰,B1不會和B2有直接關系,他們之間需要通過B模塊去傳遞。同理,B模塊和A模塊也沒有直接關系,他們都需要通過外層頁面去處理關系。
但是假如有這么一個需求,A2的顯示和B2(用戶交互)以及C101(用戶交互)相關怎么辦。
按照這種模式,它的解決方案是:
B2如果發生改變,通知B模塊,B模塊在通知頁面,頁面調用A模塊和C模塊,C模塊調用C1,C1調用C101獲取C101的數據處理,頁面調用A模塊,A模塊再調用A2,再結合一下從C101獲取的數據,改變它的展示。
是不是看著很繞,從圖上看是這么個關系:
圖中僅僅顯示了其中一個復雜交互,假如我們再多兩個模塊間關聯的邏輯:
B1和B2模塊影響A2模塊(圖中黃線)
C1影響B1模塊(圖中白線)
如下圖:
3個復雜一點的交互,整個模塊間的通信已經變成蜘蛛網了,重要的是,每一條關系線都需要開發者維護的,不僅影響開發效率,而且不好維護,容易引發bug,假如后期加新需求或者調整需求,開發成本都是比較高的。
可見,對于復雜的交互,或者模塊間關系復雜時,這種依賴父子關系的通信,是一個很大的障礙。
但是我們怎么辦,拒絕模塊化開發嗎?那樣頁面設計起來耦合度更大,更加不可維護。
首先一點,模塊化開發是一個不可逆的趨勢,然而在這種趨勢下,解決模塊化通信是一個非常重要的點。
模塊間通信其他方案在那個時候,我考慮最多的就是如何去解決模塊之間的通信,如何讓模塊之間交互更加輕松,模塊之間更加獨立。
方案一:當時考慮的一個方案是使用一個全局的event(全局的on和fire)。這樣模塊之間就不用依賴父子關系了。模塊和模塊間是可以之間交互的。
但是這樣會有一些弊端:
事件名稱如何定義,保證不重名
事件是否會重復的on
模塊和模塊之間會因為事件產生一些耦合
當交互特別復雜時,也會比較麻煩,還是上面的例子,B2通知C2改變后,C2還需要通知C101獲取一次數據,來確認改變
整體來看:
優勢: 擺脫了模塊間父子層級關系,可以簡單的跨模塊通信
劣勢: 依然需要維護復雜的模塊間關系,只是可以繞過父子依賴
方案二:全局共享一個model + component模式。這種其實已經非常趨向與數據驅動了。每個模塊都是共享全局的model,然后每個component都可以被全局獲取到到,里面的功能屬性可以直接被使用。
其實這種模式已經比較理想,頁面上面的任何component都可以被直接調用到并且使用。
個人覺得缺點就是:
多了一個全局可調用component的功能。如果砍掉他可以實現完成數據驅動,如果模塊調用時,使用多了直接獲取component的功能,還是需要在模塊間維護好和其他模塊間的交互邏輯。
先看一個圖,我感覺可以很好的體現數據驅動
提線木偶:他的特點就是每個動作都是,頭,手臂,腳,金箍棒都是由操作的人手決定的,頭和手臂直接沒有任何關系。
數據驅動也可以這么理解,頁面上面所以的展示都是由數據決定的,和頁面其他地方沒有任何關系。
再來看看上面那個例子如果加上數據驅動的設計思想。
頁面之間每個模塊,不用關心父子模塊之間的關系,每個獨立的模塊都是由一個全局的model決定。
回到上面那個麻煩的場景。當B2改變時,它會修改model中對應的數據(效驗C101數據,結合B2的改變,修改A2的數據),然后A2的業務模塊跟進A2的數據改變。
這種設計的核心是每一個模塊的改變,全部都交給model處理。
然后model里面會和個個模塊一一對應,每個模塊無需關注其他模塊的變化,只需要關注model里面對應自己數據的變化即可。所以模塊間關系鏈條會顯得非常簡單。
重點在于,當交互邏輯不斷增加時,這個關系鏈條依然不會增加,因為模塊只和model里面對于的數據相關聯。
當然,這種模式也無法去省略復雜的業務邏輯,只是業務邏輯全部都會聚集在model中。可以理解為頁面上所有的操作都是對數據的操作。然后每個模塊只需要監聽關注的數據改變即可,這個監聽關系就是圖中唯一的一條關系線。
換一個理解,我們將直接的模塊和模塊直接的耦合關系全部轉移到了數據中去體現。而數據的維護是遠遠比模塊更好維護的。
Model如何對應View還是上面頁面為例子:
model
var page = { a: { isShow: true, children: [{ a1: { isShow: true } }, { a2: { isShow: true } }] }, b: { isShow: true, children: [{ b1: { isShow: true } }, { b2: { isShow: true } }] }, c: { isShow: true, children: [{ c1: { isShow: true, children: [{ c101: { isShow: true } }] } }] } }
isShow 表示展示的意思。這個狀態對應文章第一個圖片。
當數據改變時,例如model發生變化如下:
var page = { a: { isShow: true, children: [{ a1: { isShow: true } }, { a2: { isShow: false } }] }, b: { isShow: true, children: [{ b1: { isShow: true } }, { b2: { isShow: false } }] }, c: { isShow: true, children: [{ c1: { isShow: false, children: [{ c101: { isShow: true } }] } }] } }
對應下面這樣:
換一個理解就是每一種數據狀態對應一種頁面的展示狀態。頁面想展示成什么樣子,需要數據處理成什么樣子。數據是這個頁面的核心。
數據驅動開發關注點第一點數據結構的處理,因為數據決定了整個頁面的展示,數據結構開始的設計非常關鍵,數據結構的可擴展性決定了頁面的可擴展性,如果開始數據模式不好,后期維護也會非常難受。
第二點是處理好模塊和數據中對應的關系。
可以看到數據驅動的難點和關鍵點就是數據結構的設計。而這個也是很考驗開發者能力的。數據結構的好壞直接決定了后期業務開發的質量。
數據驅動和mvc/mvvm的關系文章開頭說了,從我的角度理解數據驅動這種模式和mvc并沒有什么競爭關系,在具體的實踐中,每一個模塊可以是一個mvc或者mvvm,模塊的內部處理交給模塊自己,可以是mvc,或者單例也可以。數據驅動主要是處理模塊之間的一種邏輯。
那么為什么數據驅動和react這種結合的更加好了?因為react更進一步是講模塊內部也實現一個數據驅動,模塊內部的數據改變了,模塊的狀態會跟著改變。
微信公眾號 博客地址http://tangguangyao.github.io/
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/78620.html
摘要:之前談到過很多次數據驅動的理解,這次通過實際項目檢驗了一下自己的想法。對于數據驅動這種模式,至少從數據層,可以規避,做一層數據變化的效驗這個和寫服務端單側差不多。數據驅動和有點類似,只是借用在單頁面上實現了。 之前談到過很多次數據驅動的理解,這次通過實際項目檢驗了一下自己的想法。 相關文件 《前端數據驅動的價值》 《前端數據驅動的陷阱》 項目詳設 詳設的重要性 對于復雜一點的項目,...
摘要:業務運維是運維與企業業務深度融合的產物,是運維管理在互聯網時代和云計算大數據技術推動下的必然結果。 從信息化時代起,企業一直在試圖發現業務數據中深藏的商業價值,并為此誕生了數據挖掘、商業智能、BPM、BSM等諸多技術,然而互聯網時代的到來,專為封閉生產環境而生的信息化系統,已經無法滿足企業高速增長的互聯網開放業務和隨著而來的海量信息的處理需求。互聯網+最大的價值在于連接,企業根據原有生...
摘要:著作權歸作者所有。工作年限越長,公司對于開發者的要求就會越高。了解技術的內部機制才能讓自己不被淘汰。 著作權歸作者所有。商業轉載請聯系 Scott 獲得授權,非商業轉載請注明出處[務必保留全文,勿做刪減]。 Scott 近兩年無論是面試還是線下線上的技術分享,遇到許許多多前端同學,由于團隊原因,個人原因,職業成長,技術方向,甚至家庭等等原因,在理想國與現實之間,在放棄與堅守之間,搖擺不停,...
閱讀 3406·2021-11-24 09:39
閱讀 1797·2021-11-17 09:33
閱讀 3503·2021-10-12 10:12
閱讀 5019·2021-09-22 15:51
閱讀 1112·2019-08-30 13:11
閱讀 3572·2019-08-30 10:59
閱讀 564·2019-08-30 10:48
閱讀 1311·2019-08-26 13:48