UI框架与MVC模式详解（2）——数据管理

【内存包括全量数据】

这是最简单的情况。

有个数据管理的类，初始化时把所有需要的数据加载到内存中，提供不同的Get方法，让同一个界面获取不同的数据或者不同的界面获取相同的数据。

一般来说，对于同一种数据单位，会有一个List<数据结构>、Dic<数据标识Id,数据结构>，每多一种数据就需要一对List\Dic。

这里说的数据单位是根据实际需求抽象数来的数据对象。

例如，对于前文的例子，至少需要有：

• List<栏目数据>，Dic<栏目Id，栏目数据>，栏目数据包括栏目Id、栏目有哪些歌单即List<歌单Id>等
• List<歌单数据>，Dic<歌单Id，歌单数据>，歌单数据包括歌单Id、歌单名字、歌单点赞数、歌单封面、歌单收藏数、歌单评论数、包含的歌曲List<歌曲Id>等
• List<歌曲数据>，Dic<歌曲Id，歌曲数据>，歌曲数据包括歌曲Id、歌曲名字、歌曲作者、歌曲封面、歌曲音频数据、歌曲风格、歌曲时长、歌曲收藏数、歌曲点赞数等

这种情况下需要关注的核心问题有两个：一是数据单位，二是获取数据的方法

数据单位要大而全，因为不同界面需要的显示数据虽然都来自同一个数据单位，但有的显示数据单位中的A，而有的不会.

对每一个数据单位都提供一个唯一的根据数据单位Id来获取数据的方法。这会遇到三种情况：

1. 不同界面有同样的数据单位，直接调用数据管理类的Get方法即可
2. 不同界面数据单位有差别，例如数据管理类中有一个栏目数据单位ID为“华语”，有个界面A要显示的是“中文”，另一个界面B要显示的是“Chinese”，不能在Get的时候传入“中文”或“Chinese”，在Get方法中转换成“华语”，这种转换或者说映射关系要由各自的界面维护，或者由一个中间者维护
3. 两种不同情况交织在一起，有的地方可以直接传入数据单位Id，有的地方需要转换下，这时没必要去搞个中间者维护，直接各自维护映射关系即可

那么这里的映射关系需要有很多不同的if else吗？如果仅仅是两三个也不用拓展，用了即可。如果很多，我们要逻辑和数据分离，这里是方法层级的逻辑和数据分离，前文说的是功能层级的逻辑和数据分离

在方法层级中，数据就是传入的参数，逻辑就是方法体。而建立映射关系的逻辑直接用Dic即可

【数据需要按需加载】

这种情况稍微复杂些，面临Get时可能没有数据，需要加载，随后异步返回数据的问题。

这里多了一个简单的加载情况，我们不考虑取消加载的情况。当Get数据时，有两种情况:加载中，加载已经完成

首先，要搞清一点，数据加载的逻辑要在数据管理中完成，界面只是做调用即可，千万别把数据加载的逻辑放到界面中

我们需要有一个数据结构记录：每一个数据单位Id的数据加载状态，加载完成时直接返回数据即可，没有完成时等待加载完成通知

如何通知？使用回调函数或者消息，两者的区别不懂请看这篇文章

伪代码如下：

 // function TryGetData(数据单位Id)
 //{
 //    bool loaded =  function IsDataLoaded(数据单位Id)
 //    if loaded then 异步通知 或者 function GetData(数据单位Id)
 //  else function LoadData(数据单位Id)
 //}

 //function IsDataLoaded(数据单位Id)
 //{
 //      根据记录判断数据是否加载完成
 //}

 //function LoadData(数据单位Id)
 //{
 //    function 具体的加载逻辑{}
 //    加载完成时，向List\Dic中添加数据，标记加载完成，异步通知完成加载
 //}

 //function GetData(数据单位Id)
 //{
 //      返回数据单位
 //}

更完善的考虑

如果是第一次写加载类逻辑，写出上面类似的逻辑是不难的，但这个逻辑是有缺陷的。

例如，如果两个地方先后紧挨着调用TryGetData，且传入的数据单位ID相同，那么数据岂不是要加载两次。

为什么很容易写出这样的缺陷？因为没有将状态做好划分,也即没有理解清楚要加的功能。加载状态有三个，未加载、加载中、加载完成.

在原有功能基础上加新的功能时，需要对新功能的每个状态分别做处理

这里修改下TryGetData方法:

//function TryGetData(数据单位Id)
//{
//        根据Id获取当前加载状态
//        加载状态 == 未加载：记录调用者，LoadData(数据单位Id)
//        加载状态 == 加载中：记录调用者，
//        加载状态 == 加载完成：异步通知或者GetData(数据单位Id)
//}

更细节的思考

我们对于不同的数据单位都有各自的GetData方法，做了加载后，显然要有多个TryGetData方法。

那么是否需要有多个记录数据单位加载状态的结构呢？毕竟数据单位Id的类型不同，可能是Int，可能是float，可能是string,甚至是struct

显然易见的方法是，对每种数据单位创建一个记录加载状态的结构,但这样不易扩展,新增数据单位时,必须要在数据管理类中写好方法,界面才能使用,也即两者被耦合起来了.

解决方式如下:

1. 建立数据单位种类枚举,将Get方法的参数封装为request结构,这样对于多个数据单位甚至新增数据单位,都调用同一个TryGetData方法即可,数据管理类根据请求做不同的处理
2. 确保不同数据单位Id类型相同且不重复或者根据原有数据单位生成不重复的Id作为加载Id,以此只用一个记录加载状态的结构
3. 采用消息做异步通知或者回调的类型是object

同时，加载前需要传入必要的路径和其他可能的信息，这需要建立一个加载Id到加载所需数据的映射。

加载后对不同的数据单位而言有不同的读取数据的方法。

对于不同的数据单位，加载时的逻辑是相同的。加载前的信息和加载后的方法对加载时的逻辑而言都是数据，这是流程的逻辑数据和分离，比之前说的方法的逻辑数据和分离复杂点。

链式加载

我们考虑了相同的数据单位被同时请求加载的情况，另一种特殊的情况是大量不同的数据单位被同时请求加载。

最简单的处理方式是每次只做一个加载请求，缓存下加载请求。在Tick中一次处理这些请求，只有上一个请求完成时才开启下一次请求。没有Tick用个While循环即可，也好处理。

当然，也可以每次做多个，甚至有优先级之分，这属于如何去做加载，更多的就不讨论了。

【数据动态更新】

之前都是认为数据是不变的，但在有些情况下数据是会改变的。

在游戏场景下，数据加载后通常不会再变。而在一般前端上，加载数据要向服务器请求，后端的数据可能有实时变化，前端显示的数据也要变化。

如何知道数据是否变化？数据接收者轮询或数据发送者通知

一般后端可能对接上百万的前端，不会通知前端，需要前端轮询，这意味着我们加载数据的请求或者说网络请求需要重复执行。

因此，在调用TryGetData时需要传递是否需要重复执行的参数并记录，同时轮询要有时间间隔的参数、记录上次请求时间。

伪代码如下：

 //function TryGetData(数据单位Id,是否重复执行)
 //{
 //        计算出加载Id
 //        根据加载Id获取当前加载状态
 //        加载状态 == 未加载：记录调用者，LoadData(加载Id，是否重复执行)
 //        加载状态 == 加载中：记录调用者，
 //        加载状态 == 加载完成
 //        {
 //         需要重复执行：取上次加载时间与时间间隔：LoadData(加载Id,是否重复执行)
 //         不需要重复执行：异步通知或者GetData(数据单位Id)
 //        }
 //          
 //}

  //function LoadData(加载Id，是否重复执行)
  //{
  //    function 具体的加载逻辑{}
  //    加载完成时：{
        //            向List\Dic中添加数据
        //            不需要重复执行：标记加载完成，
        //            异步通知完成加载
        //    }
  //}

我们这里只给出了两个方法的修改，当然还有其他一些方法修改。可以看到，当我们在原有的基础上，新增功能时，必须修改原有的方法。

为了避免有所遗漏，需要将原有的涉及新功能的地方全部过一遍，如果涉及过多、或者时间不够等，那么必然会出现Bug。

失败重试

请求可能失败，失败会尝试重新请求，一般会次数限制，需要记录每个请求的次数

        //function LoadData(加载Id，是否重复执行)
        //{
        //    加载结果 =  function 具体的加载逻辑{}
        //    加载结果 == 加载完成：{
        //            向List\Dic中添加数据
        //            不需要重复执行：标记加载完成，
        //            异步通知完成加载
        //    }
        //    加载结果 == 加载失败：{
        //        根据加载Id获取请求次数
        //        请求次数++
        //        请求次数 < 次数限制：LoadData(加载Id，是否重复执行)
        //        }
        //}

数据写入

我们目前为止都是在读取数据，如果是写入数据会更简单一些，仿照读的接口实现写入接口即可。

写数据可以直接保存在本地，或通过网络请求传给服务端。

注意在写入数据后表明数据更新了，要异步通知其他读数据的地方。先写再通知，这样无论同一个数据单位被多个地方读写也没问题。

【组件化】

可以看到数据管理复杂的地方在于加载数据，当新增其他功能时会修改原有方法，修改不完全时容易出错。

为了有效减少改动，方便扩展，减少错误，需要从中提取可复用的逻辑。

在这种情况下提取复用逻辑和之前从将公用的逻辑放到一个方法中不同，这时要将整个功能涉及到的所有方法合在一起，从这些方法中提取复用的逻辑和数据。

这些可复用的逻辑就会形成一个组件，这就是组件化。

写一个通用组件必然会用到泛型并留出各种Hook接口，可以尝试将加载数据的功能从数据管理中移除，将其作为用于UI的一个组件就能明白组件化是怎么回事。

可以参考useRequest的源码和使用