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

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

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

引用nightire在segmentfault對于《前端數(shù)據(jù)驅(qū)動的價值》的評論：
我覺得非常好所以完整復制過來

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

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

但是對于這個一筆帶過的維護store其實技術含量非常高。

下面分業(yè)務場景和情況描述

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

當然，即使是新產(chǎn)品，也會遇到麻煩點，因為每一個參與開發(fā)的人，必須要全局的理解整個數(shù)據(jù)結(jié)構(gòu)。

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

模式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: {}
        }
    }
}

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

但是如果當層級關系越來越深，這個里面增刪改查信息就是一個麻煩點，可以說上面結(jié)構(gòu)的可擴展性不強。

那么換下面一種結(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
        },
    }
}

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

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

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

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

結(jié)論一：初期的數(shù)據(jù)結(jié)構(gòu)設計會是未來的不定時炸彈，遲早會面對，需要有相應策略

再來考慮評論中的一個問題：

Single Data Source 也不是萬能靈藥，如果 A B C 三個模塊都是各自獨立開發(fā)的，之后因為需求而要合并在一起，怎么辦？在它們之上再來一個 SDS？那這樣還算不算是 SDS 呢？（或者反過來，不是 SDS 的話難道就不行嗎？）

復雜的系統(tǒng)中確實會遇到這種問題，直接舉例：

模塊C，主要負責修改level:

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

模塊D，主要負責修改auth:

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

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

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

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

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

評論里面提到的這部分應該是單向數(shù)據(jù)流的一個痛點，如果模塊里面嚴格執(zhí)行單向數(shù)據(jù)流，對于這種表單驗證來說，是非常痛苦的。

例如：

var form = {
    value: 2.00
}

對應一個輸入框，輸入框只能限制輸入1-100的2位小數(shù)。整個驗證過程單向數(shù)據(jù)驅(qū)動就會特別麻煩。

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

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

個人感覺數(shù)據(jù)驅(qū)動對于開發(fā)人員的要求其實有一些增加，開發(fā)是需要更多的全局觀，對于業(yè)務需要更加的了解。這個其實算是缺點，因為從工程化的角度，這種模式提高了開發(fā)成本，提高了開發(fā)人員的學習成本。

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

總之沒有銀彈，每種模式都有適合的場景。以上就是對于數(shù)據(jù)驅(qū)動的一點點看法。僅供參考。

http://tangguangyao.github.io/