IOS移动端应用开发架构总结
写在前面
在移动应用APP开发中，架构是一个相当重要的部分，它就相当于我们盖楼时候的根基一样，一个好的架构模式，能让你的APP应对所有产品经理带来的狂风暴雨，反之，一个较差的架构，还没等你开发完毕可能就会面临到处都是奔溃的风险。
架构的重要性
我们开发的APP并不是一次性买卖，后期需要我们自己不断的去更新迭代；一个好的APP架构模式能让我们在后期迭代过程中减少开发的风险，有效的提高效率，不会因为UI的变化让我们去花费很多时间去做很多重复的工作。不论是之前的MVC模式，还是现如今的MVP/MVVM这些前端架构，都在为减少后期维护的成本而做着努力。
废话不多说，下面是我平时工作中总结出的架构模式，它并不完美，甚至还存在很多缺陷，但它对于开发一般的APP已经足够了
提炼出的业务逻辑
我将APP现有的架构按照垂直方向从上向下进行分层，分别为:
- 视图UI(这里用ViewController代替)；
- Business逻辑业务处理层；
- Base数据层；
如下图所示：
image.png
一、Base原始数据层：
进行原始数据的读写，主要涉及一些和业务无关，且可作为公共资源来访问的数据
- 读写网络最原始数据
- 读写文件系统、数据库中的原始数据
-
读写蓝牙底层数据交换信息
....
下面以读写网络数据为例：
用于和网络进行数据交换，最底层，也是最直接的方式，拿到的网络数据是最原始的。因为在当我们访问网络的时候，每一个URL对应一个远程API接口，返回的数据也是和这个URL一一对应的，所以，当要实现网络访问时，我们希望能够看到URL，就立马知道访问这个URL地址需要的参数以及返回数据。参考文章【IOS开发中Block与Delegate对于访问网络的差异】在IOS中，有代理和Block这两种方式去处理网络请求，block的方式与代理的方式相比，其有着处理数据更加简洁，更加灵活的特性，而且我们把底层数据作为元数据，并不需要处理，所以，底层使用block的形式比代理的方式好，代码如下：
+ (void)fetchDriverInfoSuccess:(void (^)(UCARDriverInfoDTO *))success failure:(void (^)(NSDictionary *, NSDictionary *, NSError *))failure {
UCARHttpRequestConfig *config = [UCARHttpRequestConfig defaultConfig];
config.subURL = UCAR_HTTP_PERSON_INFORMATION;
[[UCARHttpManager sharedManager] asyncGETWithConfig:config success:^(NSDictionary * _Nonnull response, NSDictionary * _Nullable request) {
NSDictionary *result = response[UCARHttpResponseKeyContent];
UCARDriverInfoDTO *dto = [UCARDriverInfoDTO parse:result];
if (success) {
success(dto);
}
}failure:^(NSDictionary * _Nullable response, NSDictionary * _Nullable request, NSError * _Nonnull error) {
if (failure) {
failure(response,request,error);
}
}];
}
二、Business层主要功能是：
- 负责承接上下层
- 处理业务逻辑
- 缓存数据
在business层，我这里利用delegate的方式向上传递数据，在Business层分别建立了2个基类和一个回调代理协议：
- UCARBusinessBaseService
- UCARBaseModel
- UCARBusinessBaseDelegate
image.png
子类Business直接继承UCARBusinessBaseService类进行业务处理，当网络请求成功后，会回调这2个方法：
//处理business层数据失败回调
- (void)didFailToDealWithBusinessData:(NSDictionary *)failInfo;
/// 处理business层数据成功，返回一个成功的baseModel
/// @param model 基类model
- (void)didSuccessToDealBusinessData:(UCARBaseModel *)model;
在对于需要网络请求的ViewController层，需要实现这个代理协议来等待接收网络请求反馈，然后进行处理，如果ViewController层的子View需要数据，那么我们直接传递传递business对象，如下图：
image.png
子view拿到business对象后，可以调用对应的业务处理函数，把业务处理继续下层到business，使得View、viewController的职责更加单一。
原则上来说：一个business只处理一个ViewController上的数据逻辑以及其上的view数据，但如果存在多级页面跳转，并且公用同一份数据的情况，那么，直接传递接口数据到另一个ViewController2，然后VC将此数据丢到其对应的BusinessService2中进行业务转换，当然，BusinessService2中有所有关于ViewController2的网络请求以及业务处理逻辑。
三、视图层主要功能是：
- 用户交互的处理
- 视图数据的展示
这一层主要是负责数据展示，也是我们开发APP端写的最多的东西
这一层主要核心思想是实现数据与视图的分离，分离程度越高，那么将来维护起来成本越小，比较重要的一个环节。下面我把上面的business层的数据详细展开来进行讨论，如下图：
IOS视图与数据分离处理.png
我们的目的是实现视图与数据相分离，如图所示：
1.视图控制器
主要作为一个容器视图，用来控制子视图的布局，交互；其持有BusinessService的对象。
2.视图：
每一个复合视图都必须有一个数据源，数据源包含了本视图所需的所有数据字段。
3.business模块
包含范文base层接口的对象，同时也作为转换器，可以实现将base层数据转为view层的数据，同时也包含一些页面需要的公共方法。
因为business层的存在，其实我们已经可以做到视图和数据相分离了。在开发的时候，我们可以先按照UI，把所需要的数据先在自己的business中生成，而不用等待接口过来和你对接。等接口那边完毕以后，在business对接后台数据即可。
