方式一:主项目结构按照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:顾名思义,这里存放的就是项目的各个模块了