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

年前一篇文章《前端數據驅動的價值》聊了一下數據驅動的一些看法。

其中數據驅動的核心在于整個系統中對于數據的架構，設計，維護。對于數據的處理直接決定了系統的穩定性，可維護性，可擴展性。但是這里的數據維護也是相當復雜和難搞的一塊。

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

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

對于一個真正完美的數據驅動，就如同《前端數據驅動的價值》中的例子，所有業務全部由一個store驅動，維護好store就是維護好了整個系統。

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

下面分業務場景和情況描述

這種情況是比較幸運的，開始的模型中設計好業務數據結構，設計好未來可擴展點。

當然，即使是新產品，也會遇到麻煩點，因為每一個參與開發的人，必須要全局的理解整個數據結構。

看看數據難搞的地方，舉個例子：

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

上面是一種最簡單的數據結構，清晰的展現了plan、unit、keyword直接的關系，簡單直白。

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

那么換下面一種結構是否更加合適：

模式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
        },
    }
}

個人感覺這種模式更加適合，便于查找和更新，那么問題來了，先拋開哪種數據結構更合適問題，假如開發初期模式A是ok的，隨著業務的復雜，發現模式A越來越難維護，經過重新設計，發現轉換到模式B更加合適，能明顯提高開發和維護效率，那么怎么辦？

個人還沒有實踐過，但是經驗上看感覺是會導致大面積重構。即使重構完成，假如后期發現更好的數據模式呢？

所以可以看出初期的數據結構決定了未來架構，看上去像不像后端開發，數據庫的設計很重要。

既然越來越像后端設計模式，那么是否會模仿當時的前后端分離策略，底層數據結構和業務展現通過api實現呢？個人感覺這樣有點問題過于復雜化。那么是否可以加一個中間數據轉換層去處理數據呢？這樣在底層數據結構變換時，也能避免直接影響業務模塊，中間層做一個適當的解耦，展示內容和數據結構沒有什么關聯，關聯的僅僅是數據信息。

結論一：初期的數據結構設計會是未來的不定時炸彈，遲早會面對，需要有相應策略

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

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

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

模塊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
    }
}

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

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

結論二：數據驅動下，數據的重復和同步是一個坑，要盡量避免

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

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

例如：

var form = {
    value: 2.00
}

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

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

結論三:對于某些具體的模塊，單向數據流不是萬靈藥，整體架構單向數據驅動，具體模塊可以根據場景選擇最合適的

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

那么優點呢，應該是系統的穩定性，可維護性，健壯性會更好。

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

http://tangguangyao.github.io/