软件开发数据解析思路

标准的数据解析：

标准数据解析的过程.png

什么是ResponseModel：对服务端下发数据的全量解析，使用第三方库MJExtension可以保证存在ResponseModel中的属性都是正确的值。

什么是BuisnessModel：面向业务层的Model，里面的属性专为View准备，对View来说是充分必要是数据，由多个ResponseModel或者一个ResponseModel中的一部分组装而成。

两种方式：第一种方式是为每一个View准备一个Model，第二种方式是一个Model中的数据能够展示多个View，我们一般在日常开发中第二种用的比较多。

标准的数据解析存在的问题：

1. 可读性差

   ResponseModel是与网络请求接口一一对应的（意味着命名似乎也要按照接口来命名），在不完美的情况下(特指服务端的数据很乱，或者在一些紧急迭代中，服务端没有时间去整理成客户端想要的充分必要数据)，就是出现脱离业务的状态，在下一个代码阅读者的眼中，除了详细的注释，很难直观的看懂这个Model的用意，而这样的Model散落在业务VC中，造成难以阅读的问题。

2. 效率低

   在以上流程中，Dictionary -> Model1 -> Model2，通过三层转换才将服务端的数据转换成View所需要的数据。

水龙头式的数据解析：

水龙头式数据解析 (1).jpg

Reformer是什么：改造器，将服务端的数据改造成view能用的充分必要数据。

为什么给View提供字典：

• 字典转字典 比 字典转Model更加有效率

• 数据结构具有通用性：与服务端沟通是，一般是用JSON格式的，基本沿用字典的形式，能一目了然的看到数据结构。

• 调试便捷：字典格式的数据在调试阶段，能直接po出数据格式。

怎么解决字典的Ke、y是文本式难以在编译时期保证正确性的问题：

1. 在Reformer中改造数据时，.m文件中以 ReformerName + KeyName 的格式实现Reformer改造后的数据的key。

2. 创建以ReformerName + Keys为文件名的.h文件，将Reformer中的Key全部extern出去。

3. 如果不知道Reformer改造后字典中的key的，可以直接引用Keys文件，调用字典中的values。

水龙头式的数据解析的好处：

1. 减少了数据转化的次数，提升了效率。

2. 业务友好：数据转换的逻辑都被分散到了Reformer中，VC只需要选择不同的Reformer就可以了。