摘要：結(jié)論三對(duì)于某些具體的模塊，單向數(shù)據(jù)流不是萬(wàn)靈藥，整體架構(gòu)單向數(shù)據(jù)驅(qū)動(dòng)，具體模塊可以根據(jù)場(chǎng)景選擇最合適的總結(jié)個(gè)人感覺(jué)數(shù)據(jù)驅(qū)動(dòng)對(duì)于開(kāi)發(fā)人員的要求其實(shí)有一些增加，開(kāi)發(fā)是需要更多的全局觀，對(duì)于業(yè)務(wù)需要更加的了解。

年前一篇文章《前端數(shù)據(jù)驅(qū)動(dòng)的價(jià)值》聊了一下數(shù)據(jù)驅(qū)動(dòng)的一些看法。

其中數(shù)據(jù)驅(qū)動(dòng)的核心在于整個(gè)系統(tǒng)中對(duì)于數(shù)據(jù)的架構(gòu)，設(shè)計(jì)，維護(hù)。對(duì)于數(shù)據(jù)的處理直接決定了系統(tǒng)的穩(wěn)定性，可維護(hù)性，可擴(kuò)展性。但是這里的數(shù)據(jù)維護(hù)也是相當(dāng)復(fù)雜和難搞的一塊。

引用nightire在segmentfault對(duì)于《前端數(shù)據(jù)驅(qū)動(dòng)的價(jià)值》的評(píng)論：
我覺(jué)得非常好所以完整復(fù)制過(guò)來(lái)

數(shù)據(jù)驅(qū)動(dòng)肯定不是從 flux/redux + react 才開(kāi)始的
上者特別強(qiáng)調(diào)單向數(shù)據(jù)流，所以才給人造成“由它開(kāi)始”的錯(cuò)覺(jué)
單向數(shù)據(jù)流有一個(gè)前置依賴(lài)，那就是 Single Data Source，也就是你的“提線(xiàn)木偶”所描述的那樣
然而在你的文章里卻把它寫(xiě)成了 Data Driven 的前置依賴(lài)
問(wèn)題來(lái)了：只有單向數(shù)據(jù)流才算數(shù)據(jù)驅(qū)動(dòng)嗎？
肯定不是的，其實(shí)老牌的 Angular／Ember／……等等都是一樣的，無(wú)非就是對(duì)待 Data 的方式各有不同罷了；刨除這些細(xì)微差別，它們都是從 “DOM 驅(qū)動(dòng)” 轉(zhuǎn)向 “數(shù)據(jù)驅(qū)動(dòng)” 的代表作品
只是它們并沒(méi)有把這個(gè)的概念提煉的深入人心，如此說(shuō)來(lái)，React 一家是功不可沒(méi)的，不可變數(shù)據(jù) ＋ 單向數(shù)據(jù)流讓數(shù)據(jù)驅(qū)動(dòng)真正成為了“理念”，而不只是“概念”
然而，單向數(shù)據(jù)流也不是十全十美的，對(duì)于 UI 編程來(lái)說(shuō)，有些地方的確是雙向綁定來(lái)得更“漂亮”一些，比如：表單
所以 React 也適時(shí)的加入了雙向綁定；不過(guò)這并不妨礙數(shù)據(jù)驅(qū)動(dòng)這一理念得以貫徹
Single Data Source 也不是萬(wàn)能靈藥，如果 A B C 三個(gè)模塊都是各自獨(dú)立開(kāi)發(fā)的，之后因?yàn)樾枨蠖喜⒃谝黄穑趺崔k？在它們之上再來(lái)一個(gè) SDS？那這樣還算不算是 SDS 呢？（或者反過(guò)來(lái)，不是 SDS 的話(huà)難道就不行嗎？）
這個(gè)問(wèn)題其實(shí)也還在發(fā)展中，這會(huì)兒我也給不出答案，只是客觀描述一番罷了。

對(duì)于一個(gè)真正完美的數(shù)據(jù)驅(qū)動(dòng)，就如同《前端數(shù)據(jù)驅(qū)動(dòng)的價(jià)值》中的例子，所有業(yè)務(wù)全部由一個(gè)store驅(qū)動(dòng)，維護(hù)好store就是維護(hù)好了整個(gè)系統(tǒng)。

但是對(duì)于這個(gè)一筆帶過(guò)的維護(hù)store其實(shí)技術(shù)含量非常高。

下面分業(yè)務(wù)場(chǎng)景和情況描述

這種情況是比較幸運(yùn)的，開(kāi)始的模型中設(shè)計(jì)好業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)，設(shè)計(jì)好未來(lái)可擴(kuò)展點(diǎn)。

當(dāng)然，即使是新產(chǎn)品，也會(huì)遇到麻煩點(diǎn)，因?yàn)槊恳粋€(gè)參與開(kāi)發(fā)的人，必須要全局的理解整個(gè)數(shù)據(jù)結(jié)構(gòu)。

看看數(shù)據(jù)難搞的地方，舉個(gè)例子：

模式A:

var store = {
    userInfo: {
        name: "test",
        age: "20"
    },
    planNum: 2,
    plans: {
        "plan1": {
            name: "plan1",
            price: 2.00,
            unitNum: 1,
            unit: {
                "unit1": {
                    name: "unit1",
                    price: 1.22,
                    keywordNum: 2,
                    keyword: {
                        "keyword1": {
                            name: "word1",
                            price: 22.00
                        },
                        "keyword2": {
                            name: "word2",
                            price: 21.00
                        }
                    }
                }
            }
        },
        "plan2": {
            name: "plan2",
            price: 3.00,
            unitNum: 0,
            unit: {}
        }
    }
}

上面是一種最簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)，清晰的展現(xiàn)了plan、unit、keyword直接的關(guān)系，簡(jiǎn)單直白。

但是如果當(dāng)層級(jí)關(guān)系越來(lái)越深，這個(gè)里面增刪改查信息就是一個(gè)麻煩點(diǎn)，可以說(shuō)上面結(jié)構(gòu)的可擴(kuò)展性不強(qiáng)。

那么換下面一種結(jié)構(gòu)是否更加合適：

模式B:

var store = {
    userInfo: {
        name: "test",
        age: "20"
    },
    planNum: 2,
    plans: {
        "plan1": {
            name: "plan1",
            price: 2.00,
            unitNum: 1,
            unit: [unit1]
        },
        "plan2": {
            name: "plan2",
            price: 3.00,
            unitNum: 0,
            unit: []
        }
    },
    units: {
        "unit1": {
            plan: "plan1",
            name: "unit1",
            price: 1.22,
            keywordNum: 2,
            keyword: [keyword1]
        }
    },
    keywords: {
        "keyword1": {
            plan: "plan1",
            unit: "unit1",
            name: "word1",
            price: 22.00
        },
        "keyword1": {
            plan: "plan1",
            unit: "unit1",
            name: "word2",
            price: 21.00
        },
    }
}

個(gè)人感覺(jué)這種模式更加適合，便于查找和更新，那么問(wèn)題來(lái)了，先拋開(kāi)哪種數(shù)據(jù)結(jié)構(gòu)更合適問(wèn)題，假如開(kāi)發(fā)初期模式A是ok的，隨著業(yè)務(wù)的復(fù)雜，發(fā)現(xiàn)模式A越來(lái)越難維護(hù)，經(jīng)過(guò)重新設(shè)計(jì)，發(fā)現(xiàn)轉(zhuǎn)換到模式B更加合適，能明顯提高開(kāi)發(fā)和維護(hù)效率，那么怎么辦？

個(gè)人還沒(méi)有實(shí)踐過(guò)，但是經(jīng)驗(yàn)上看感覺(jué)是會(huì)導(dǎo)致大面積重構(gòu)。即使重構(gòu)完成，假如后期發(fā)現(xiàn)更好的數(shù)據(jù)模式呢？

所以可以看出初期的數(shù)據(jù)結(jié)構(gòu)決定了未來(lái)架構(gòu)，看上去像不像后端開(kāi)發(fā)，數(shù)據(jù)庫(kù)的設(shè)計(jì)很重要。

既然越來(lái)越像后端設(shè)計(jì)模式，那么是否會(huì)模仿當(dāng)時(shí)的前后端分離策略，底層數(shù)據(jù)結(jié)構(gòu)和業(yè)務(wù)展現(xiàn)通過(guò)api實(shí)現(xiàn)呢？個(gè)人感覺(jué)這樣有點(diǎn)問(wèn)題過(guò)于復(fù)雜化。那么是否可以加一個(gè)中間數(shù)據(jù)轉(zhuǎn)換層去處理數(shù)據(jù)呢？這樣在底層數(shù)據(jù)結(jié)構(gòu)變換時(shí)，也能避免直接影響業(yè)務(wù)模塊，中間層做一個(gè)適當(dāng)?shù)慕怦睿故緝?nèi)容和數(shù)據(jù)結(jié)構(gòu)沒(méi)有什么關(guān)聯(lián)，關(guān)聯(lián)的僅僅是數(shù)據(jù)信息。

結(jié)論一：初期的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)會(huì)是未來(lái)的不定時(shí)炸彈，遲早會(huì)面對(duì)，需要有相應(yīng)策略

再來(lái)考慮評(píng)論中的一個(gè)問(wèn)題：

Single Data Source 也不是萬(wàn)能靈藥，如果 A B C 三個(gè)模塊都是各自獨(dú)立開(kāi)發(fā)的，之后因?yàn)樾枨蠖喜⒃谝黄穑趺崔k？在它們之上再來(lái)一個(gè) SDS？那這樣還算不算是 SDS 呢？（或者反過(guò)來(lái)，不是 SDS 的話(huà)難道就不行嗎？）

復(fù)雜的系統(tǒng)中確實(shí)會(huì)遇到這種問(wèn)題，直接舉例：

模塊C，主要負(fù)責(zé)修改level:

var store = {
    moduleA: {
        "plan1": {
            name: "plan1",
            price: 22.00
        },
        level: 2
    }
}

模塊D，主要負(fù)責(zé)修改auth:

var store = {
    moduleB: {
        "plan1": {
            name: "plan1",
            price: 22.00
        },
        auth: 0
    }
}

現(xiàn)在的邏輯是假如兩個(gè)獨(dú)立開(kāi)發(fā)好的模塊需要合并到一起，他們都有各自模塊的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，假如模塊C除了修改level，還修改了plan1的name會(huì)怎么樣？為了保證數(shù)據(jù)統(tǒng)一，需要去找到模塊D中的plan1信息，并且修改。假如他們都合并到上面一個(gè)例子模塊A中怎么辦，是否還需要繼續(xù)同步修改。如果漏掉一個(gè)同步，展示上，以及后面的處理都會(huì)引發(fā)各種bug。

當(dāng)然，如果不用數(shù)據(jù)驅(qū)動(dòng)，可能這種模塊合并也是需要從展示層級(jí)各處同步修改信息的，也會(huì)特別麻煩。只是相比較而言，數(shù)據(jù)驅(qū)動(dòng)的這種合并同步并沒(méi)有給我們帶來(lái)很清晰簡(jiǎn)單的處理方式。

結(jié)論二：數(shù)據(jù)驅(qū)動(dòng)下，數(shù)據(jù)的重復(fù)和同步是一個(gè)坑，要盡量避免

然而，單向數(shù)據(jù)流也不是十全十美的，對(duì)于 UI 編程來(lái)說(shuō)，有些地方的確是雙向綁定來(lái)得更“漂亮”一些，比如：表單

評(píng)論里面提到的這部分應(yīng)該是單向數(shù)據(jù)流的一個(gè)痛點(diǎn)，如果模塊里面嚴(yán)格執(zhí)行單向數(shù)據(jù)流，對(duì)于這種表單驗(yàn)證來(lái)說(shuō)，是非常痛苦的。

例如：

var form = {
    value: 2.00
}

對(duì)應(yīng)一個(gè)輸入框，輸入框只能限制輸入1-100的2位小數(shù)。整個(gè)驗(yàn)證過(guò)程單向數(shù)據(jù)驅(qū)動(dòng)就會(huì)特別麻煩。

一個(gè)簡(jiǎn)單的例子，在使用react實(shí)現(xiàn)表單驗(yàn)證就比較麻煩。

結(jié)論三:對(duì)于某些具體的模塊，單向數(shù)據(jù)流不是萬(wàn)靈藥，整體架構(gòu)單向數(shù)據(jù)驅(qū)動(dòng)，具體模塊可以根據(jù)場(chǎng)景選擇最合適的

個(gè)人感覺(jué)數(shù)據(jù)驅(qū)動(dòng)對(duì)于開(kāi)發(fā)人員的要求其實(shí)有一些增加，開(kāi)發(fā)是需要更多的全局觀，對(duì)于業(yè)務(wù)需要更加的了解。這個(gè)其實(shí)算是缺點(diǎn)，因?yàn)閺墓こ袒慕嵌龋@種模式提高了開(kāi)發(fā)成本，提高了開(kāi)發(fā)人員的學(xué)習(xí)成本。

那么優(yōu)點(diǎn)呢，應(yīng)該是系統(tǒng)的穩(wěn)定性，可維護(hù)性，健壯性會(huì)更好。

總之沒(méi)有銀彈，每種模式都有適合的場(chǎng)景。以上就是對(duì)于數(shù)據(jù)驅(qū)動(dòng)的一點(diǎn)點(diǎn)看法。僅供參考。

http://tangguangyao.github.io/