P项目的开发是一个比较发杂的SPA，各个模块都被抽成独立组件进行开发。各个组件会相互通讯，产生数据交互，也会产生独立的数据流。

在P项目中，采用了Flux，单向数据流的思想在项目中得到了很好地体现，对于部分数据交互，则用中间层做辅助，但是，我们从直接数据流开始说起吧。

直接数据流

Ajax的出现带来了极好的用户体验。当用户产生一个交互，如输入、点击等，要产生数据变化时，可以直接利用Ajax想后台程序请求数据，然后将数据填充到前台的对应元素中，展示给用户。这就产生了直接数据流。

//搜索框
var $search = $('input');
 $search.keyup(function () {
		if($(this).val() !== ''){
		    $.ajax({
                    url: './res.php',
                    method: 'POST',
                    contentType: "application/json",
                    dataType: 'json',
                    data: JSON.stringify({
                        key: $(this).val()
                    }),
                    success: function(data){
                        //todo
                    }
                })
            }
        });

res.php拿到值之后，则根据关键字搜索结果：

//省略。。。
$res = mysqli_query('select de1,de2 from userdb where username = '  + value);

数据流向应该是这样子的：

这种方式简单方便，但是安全性不够。

间接数据流

相对于直接数据流，间接数据流则对数据的传递过程作了中间层的封装，只将接口暴露给调用者，根据不同的请求url、方法和参数等返回不同的json数据。

简单地说，A想要买6s，知道C是卖6s的，却不能直接和C见面，但B可以，于是A找B帮他买6s，所以A把钱给了B，B从C那里买回了6s，然后又给了A。

还是以用户搜索为例，在前端页面中，携带用户搜索的关键字向中间层Node发送请求：

//搜索框
var $search = $('input');
 $search.keyup(function () {
		if($(this).val() !== ''){
		    $.ajax({
                    url: '/api/user/res.json',
                    method: 'POST',
                    contentType: "application/json",
                    dataType: 'json',
                    data: JSON.stringify({
                        key: $(this).val()
                    }),
                    success: function(data){
                        //todo
                    }
                })
            }
        });

/api/user/res.json是node提供给前端调用的接口，并返回给前端一个用户的搜索结果，在Node中，因为没有操作数据库，则要拿到key，向PHP为其提供的接口发送一次请求：

module.exports.register = function(router){
  router.post('/api/person/personInfo.json',getPersonInfo);
};

/api/person/personInfo.json则是PHP暴露出得接口，PHP则返回从数据库中的搜索结果给Node，Node再返回给前端，Node就充当了B的角色。

数据流向应该是这样子的：

这种方式开虽然增加了开发成本，但是安全性得到了较好地保障，并增强了代码的可维护性。

单向数据流

从数据流向来说，单向数据流是间接数据流的一种体现。Facebook推出的React深受开发者的热爱，其组件化的开发方式增强了软件的可维护性，与之伴随的Flux思想（单向数据流）则为各独立的组件提供了一种可靠的通讯方式：

搜索框作为独立的组件A，显示搜索结果的列表为组件B：

A产生输入行为(Action)，接着注册Dispatcher，在其中调用对应的Store去获取数据更新B(View)：

上边的图表当中, Dispatcher, Store 和 View 分别是独立的节点, 有明确的输入和输出.
其中 Action 是一个简单分离的, 语义化的辅助方法用来帮助传送数据到 Dispatcher.

所以数据以 Dispatcher 为中心集线器流过.Action 主要是原子用户在 View 上的操作, 仅仅是到 Dispatcher 的一个调用.Dispatcher 随后触发 Store 注册到上面的事件, 有效地把 Action 负载的数据分发到所有 Store.通过他们注册的事件, Store 决定哪些 Action 是他们需要的, 然后针对他们进行响应.Store 返回发出一个 “change”事件提醒数据所在那层的 Controller-View.

Controller-View 监听这些事件, 并通过事件回调从 Store 获取到数据.
Controller-View 然后通过 setState() 或者 forceUpdate() 调用其 render() 方法,更新自身以及全局子节点。

这个结构让我们能佷快在应用中查找原因，应用的状态仅仅在 Store 当中维护, 允许应用的不同部分高度地解耦.
Store 之间不存在依赖, 他们保持了严格的层级关系, 还有通过 Distatcher 同步维护的更新