个人对ios架构层次的理解

通常我们做一个应用，无非就是调用API 展示页面 ，然后跳转到其他页面再调用API再展示页面。然而为何需要架构呢？

1.调用网络API：应该让开发工程师方便安全的调用网络API，尽可能保证 用户在 各种网络环境下都有良好的体验。

2.页面展示：    要考虑页面如何组织才能尽可能降低业务方代码的耦合度，降低业务方开发界面的复杂度，提高效率

3.数据本地持久化：当数据在本地 存取时候，保证数据在 本地的合理安排，减小性能消耗

4.动态部署方案：iOS应用有审核周期，如果通过不发布版本的 方式展示新内容给用户，最快修复紧急bug

一个好的架构要具备一下几点：

1。代码整齐，分类明确，没有common

2.不用文档，或者很少文档，就能让业务方上手

3.思路和方法要统一

4.没有横向依赖，万不得已，不能出现跨层 访问

5。容易测试和拓展

6.保持一定量的超前性

7.接口少，参数少

8.高性能

我们目前常用的架构中有三层架构的：展现层，业务层，数据层。也有四层的：展现层，业务层，网络层，本地数据层  这个没有一个特定规范，主要针对模块分类而言

 

接下来给大家简单介绍一下我架构一个项目的基本流程：

项目分为三层：UI层、BLL层、Common层

UI层：我会创建 一个BaseViewController类，里面会做一些比较基础的设置：如（标题，返回按钮，键盘通知，alertView，MBProgressHUD,网络监测）但是只可以暴露出方法，不可以暴露出属性

BLL层：处理与UI层和Common层的交互，比如网络请求，我会创建 一个基础的Request，这个 类对外只接收参数，其他什么都不做，内部是原始的网络请求，然后 建立一个BaseServer来确定是post还是get请求，指定指定的功能请求 例如：BaseServer +Login  BaseServer + Register

至于Common层：主要存放第三方类，自定义工具类，和一些宏定义