数据驱动应该是从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更进一步是讲模块内部也完成一个数据驱动，模块内部的数据转变了，模块的状况会随着转变。
微信民众号
