iOS 项目框架搭建

方式一：主项目结构按照MVC层次划分，内部结构再按照项目功能模块划分

采用这种分类方式可以将项目分为 Model，Controller，View三层，然后 Model 里面存放各个模块的 model，所有控制器全部放在 Controller 中，视图则放在 View 里面，然后相应的逻辑再根据 MVC 划分
* 优点：业务层次十分清晰
* 缺点：每个模块之间过于分散，很难准确的找到相应的模块，影响开发效率

方式二：主项目目录按照模块功能划分，内层目录再按照 MVC 划分

这种方式在项目中比较常见，在项目开始之前我们应该先对项目的结构做一个整体的划分，了解项目有哪些主要模块，模块中的功能有哪些，弄懂了这些就可以开始了。首先将自己的模块分类，然后在内部用方式一对每一种功能进行分类
* 优点：可以清晰的看出由那些功能组成，提高开发效率
* 缺点：划分过于详细，通用类存放的位置不好决定

最优解：方式一和方式二结合使用，将通用类单独划分出来

第一点：方式一和方式二没有绝对的熟好熟劣，在项目中我们应该将两者结合起来使用，就像上面的分类方式，先将项目的大体框架用第二种方式搭建起来，然后在每个模块内部用第一种方式去划分，但是不建议层级数超过三层，除非是一些极其复杂的项目，模块层级过于繁琐，否则只会让项目开起来杂乱无章，大大降低开发效率。

第二点：在项目中我们会遇到很多通用类，如果将他们放在每个模块的内部，使用起来会非常不方便，我们可以将这些通用类单独的划分出来，比如很多工具类，对网络请求的封装，宏定义和项目中所用到的图片文件等等都可以单独的划分出来，分别做一个目录，就像我上面做的那样。

• Main：专门存放AppDelegate或者AppDelegate的Category
• Util：用来存放工具类，比如我们对字符串常用的一些操作
• Resource：用来存放 app 中的一些资源，比如图片、文本等
• HTTP：用来封装网络请求，基本上每个项目都会用到，是项目中比较重要的一个部分，所以这里有将他们做了一次划分
  
  • Protocol ：将每个模块中所用到的网络请求的回调函数做一个整合
  • API ：将项目中所用到的 URL 和每个 URL 对应的请求头，请求体做一个封装
  • Manager ：对 AFNetworking 第三方库的重新封装，把请求数据做一个处理，回传时直接返回对应的 Model
• Vender：用来存放项目中所用到的第三方库文件
• Base：存放一些基类,比如BaseViewController,BaseModel等,共性直接在基类中去修改，我在这里对 UITabBarController 做了一次封装
• Custom：这里用来存放一些项目中有特色的自定义视图，比如我们常见的上拉加载,下拉刷新的自定义头部空间等
• Classes：顾名思义，这里存放的就是项目的各个模块了