iOS项目结构

Group 还是Feature

先上下前后两个项目的结构对比图：

 

 

旧的项目采用Group的方式，MVC结构，问题如下

• 随着项目的复杂度不断上升，Controller，View文件夹变得异常庞大，定位某个具体业务对应的页面往往取决于文件名命名的好坏。
• 具体业务的Controller，View，Model文件过于分散，通常无法在文件目录里面全部显示，不利于阅读，也不便于对应文件之间的跳转
• 如果多人开发，则代码在文件夹层次必然相互干扰。

新的项目采用Feature方式，MVVC结构，优点如下：

• 模块的区分便于理解产品的功能，文件的层次也基本反映了实际页面上的层次关系，便于快速定位到代码文件
• 便于协同开发，各人仅需维护自己的Feature文件夹，进行单元测试，减少了合并冲突的问题
• 同一Feature的Controller，View，Model， ViewModel在同一目录，便于阅读

具体

• vender：第三方库，大部分第三方库均采用cocoapod方式引入，其他要源码引入的一般放在这里
• Feature：业务具体模块，可以按功能进行划分，例如Login，More，Game
• Manage：管理类，通常封装了对应用的某一块操作，例如网络请求管理模块，缓存管理模块，下载管理模块。
• Utilite：工具模块，通常包括自定义的界面控件，对第三方库的简单封装类，通用工具函数类（与Manage主要区别在于Utilite复用性更强，而Manage则与项目耦合更紧密）
• Application:这个group中放的是AppDelegate和一些系统常量及系统配置文件
• Storage：简单数据存储，主要是一些键值对存储及系统外部文件的存取，包括对NSUserDefault和plist存取的封装；
• Database：数据层，封装基于FMDB的sqlite数据库存取和管理(RTDatabaseHelper)，对外提供基于Model层对象的调用接口，封装对数据的存储过程。
• Resource：资源库，包括图片，plist文件等
• General：主要包含Additions，Macros文件夹，其中Macros包含

1. NotificationMacro：通知宏定义文件
2. AppMacro：应用内外网接口，APP_ClientId等和应用相关的宏
3. UtilsMacro: 常用代码简写相关
4. UrlMacro: web请求接口路径对应的宏，将请求地址统一管理，便于查找与更新
5. EnumMacro：项目里面枚举一部分直接定义在所用枚举的文件头部，另一部分统一放在该文件，权衡的依据是如果枚举仅仅只跟界面相关，或者写了个通用类，反之，这些与业务相关的代码应该归到EnumMacro

 

 

 

作者：二木又土
链接：https://www.jianshu.com/p/a0b4a894d58a
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。