IOS移动端应用开发架构总结,移动IOS开发框架

本文讲述了IOS移动端应用开发架构总结,移动IOS开发框架。

写在前面

在移动应用APP开发中，架构是一个相当重要的部分，它就相当于我们盖楼时候的根基一样，一个好的架构模式，能让你的APP应对所有产品经理带来的狂风暴雨，反之，一个较差的架构，还没等你开发完毕可能就会面临到处都是奔溃的风险。

架构的重要性

我们开发的APP并不是一次性买卖，后期需要我们自己不断的去更新迭代；一个好的APP架构模式能让我们在后期迭代过程中减少开发的风险，有效的提高效率，不会因为UI的变化让我们去花费很多时间去做很多重复的工作。不论是之前的MVC模式，还是现如今的MVP/MVVM这些前端架构，都在为减少后期维护的成本而做着努力。

废话不多说，下面是我平时工作中总结出的架构模式，它并不完美，甚至还存在很多缺陷，但它对于开发一般的APP已经足够了

提炼出的业务逻辑

我将APP现有的架构按照垂直方向从上向下进行分层，分别为:

• 视图UI(这里用ViewController代替)；

• Business逻辑业务处理层；

• Base数据层；

如下图所示：

一、Base原始数据层：

进行原始数据的读写，主要涉及一些和业务无关，且可作为公共资源来访问的数据

1. 读写网络最原始数据

2. 读写文件系统、数据库中的原始数据

3. 读写蓝牙底层数据交换信息
   ....

下面以读写网络数据为例：
   用于和网络进行数据交换，最底层，也是最直接的方式，拿到的网络数据是最原始的。因为在当我们访问网络的时候，每一个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层主要功能是：

1. 负责承接上下层

2. 处理业务逻辑

3. 缓存数据

在business层，我这里利用delegate的方式向上传递数据，在Business层分别建立了2个基类和一个回调代理协议：

• UCARBusinessBaseService

• UCARBaseModel

• UCARBusinessBaseDelegate

子类Business直接继承UCARBusinessBaseService类进行业务处理，当网络请求成功后，会回调这2个方法：

//处理business层数据失败回调- (void)didFailToDealWithBusinessData:(NSDictionary *)failInfo;
 
 /// 处理business层数据成功，返回一个成功的baseModel/// @param model 基类model- (void)didSuccessToDealBusinessData:(UCARBaseModel *)model;

在对于需要网络请求的ViewController层，需要实现这个代理协议来等待接收网络请求反馈，然后进行处理，如果ViewController层的子View需要数据，那么我们直接传递传递business对象，如下图：

子view拿到business对象后，可以调用对应的业务处理函数，把业务处理继续下层到business，使得View、viewController的职责更加单一。
原则上来说：一个business只处理一个ViewController上的数据逻辑以及其上的view数据，但如果存在多级页面跳转，并且公用同一份数据的情况，那么，直接传递接口数据到另一个ViewController2，然后VC将此数据丢到其对应的BusinessService2中进行业务转换，当然，BusinessService2中有所有关于ViewController2的网络请求以及业务处理逻辑。

三、视图层主要功能是：

1. 用户交互的处理

2. 视图数据的展示

这一层主要是负责数据展示，也是我们开发APP端写的最多的东西

这一层主要核心思想是实现数据与视图的分离，分离程度越高，那么将来维护起来成本越小，比较重要的一个环节。下面我把上面的business层的数据详细展开来进行讨论，如下图：

我们的目的是实现视图与数据相分离，如图所示：

1.视图控制器
主要作为一个容器视图，用来控制子视图的布局，交互；其持有BusinessService的对象。
2.视图：
每一个复合视图都必须有一个数据源，数据源包含了本视图所需的所有数据字段。
3.business模块
包含范文base层接口的对象，同时也作为转换器，可以实现将base层数据转为view层的数据，同时也包含一些页面需要的公共方法。

因为business层的存在，其实我们已经可以做到视图和数据相分离了。在开发的时候，我们可以先按照UI，把所需要的数据先在自己的business中生成，而不用等待接口过来和你对接。等接口那边完毕以后，在business对接后台数据即可。