转载

前端数据驱动的陷阱

年前一篇文章《前端数据驱动的价值》聊了一下数据驱动的一些看法。

其中数据驱动的核心在于整个系统中对于数据的架构，设计，维护。对于数据的处理直接决定了系统的稳定性，可维护性，可扩展性。但是这里的数据维护也是相当复杂和难搞的一块。

精选评论

引用 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实现呢？个人感觉这样有点问题过于复杂化。那么是否可以加一个中间数据转换层去处理数据呢？这样在底层数据结构变换时，也能避免直接影响业务模块，中间层做一个适当的解耦，展示内容和数据结构没有什么关联，关联的仅仅是数据信息。

结论一：初期的数据结构设计会是未来的不定时炸弹，迟早会面对，需要有相应策略

模块合并

再来考虑评论中的一个问题：

复杂的系统中确实会遇到这种问题，直接举例：

模块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。

当然，如果不用数据驱动，可能这种模块合并也是需要从展示层级各处同步修改信息的，也会特别麻烦。只是相比较而言，数据驱动的这种合并同步并没有给我们带来很清晰简单的处理方式。