工程结构架构，减少耦合混乱以及防治需求大改造成结构重构，如何构建稳定可扩展可变换的工程结构的思考

我打算采用Information flow的方式自上而下，两大层分为基础层和展现层的结构。基础层分为多层，展现层也可分为多层。主要思想是将基础层的最下一层当做零部件，将业务层最下层当做组装大部件，通过流程串起来形成一个完整的产品，做零件时按照做出一个就扔进对应基础层的篮子里思路来，目录结构也可以按照这种来进行。这两大层的最下层按照零件拆得越小越容易应对需求变化越容易保护巩固上层的思路来就好。拿微信这个大家都熟悉的产品的几个功能来简单示例说明下这个思路构建后的结构，模块比较多，一些模块就不深入到最底层分析了：

基础层－ 网络－－ 收发数据－－－单例（持续使用数据）－－－本地（缓存和持续化存储数据对业务的封装输出）－－－单次使用（API接口Model封装输出和业务逻辑封装的ViewModel，将这些做为业务零件）－ 存储－－－ NSUserDefault（对轻量需要存储的添加下一层业务零件封装）－－－ keychain（对安全级别较高需要存储的添加下一层业务零件封装）－－－ 文件存储（对时效需求短的需要存储的添加下一层业务零件封装）－－－ 数据库存储（对数据量大的需要存储的添加下一层业务零件封装，业务层上一层加一层封装CoreData或SQLite方便日后切换数据库用）－ 动画（下层将动画框架输出成各个可以复用的动画功能小零件）－ 视图风格－ 列表控件－－ 上拉加载更多－－ 下拉刷新－－ GuideView－ WebView控件－ AlertView－ iOS系统空间封装－－ 拍照控件－－ 通讯录－ 二维码－ 语音－ 安全－ 支付－ 统计－ 日志展现层－ 首页－－ 订阅－－ 扫描二维码－－ 发布视频－ 列表－－ 时间轴列表－－－ Listview头部封面－－－ 外链情况Cell－－－ 图片Cell－－－ 广告插入Cell－－－ 留言评论－－－ 赞区域－－ 我的列表－－ 订阅列表－－ 文章列表－ 详细页－－ 分享－－ 内容区－－ 评论－ 登录－－ 注册－－ 登录－－ 忘记密码－－ 条款－－ 上传头像－－ 个人信息修改

基础层中各个模块上层可以使用类似CocoaPod或Cathage方式，下一层再对其引用进行业务封装。

这里注意最下层需要拆的粒度越细越好。减少横向依赖。类似Common这样的东西可以拆到基础层的对应模块里，比如说配置文件里和统计相关的放到基础层的统计里，网络相关的放到网络里，颜色字体放到视图风格里，不要都堆在一个文件里。再或者是各种第三方的Category也放到对应的组里，比如说UIView+Additions和UIColor+Expanded就放到视图风格这个模块中，不要专门搞个Category放所有的Category。

数据流控制模式MVC和MVCS/MVVM/VIPER的选择

其实这些都是对MVC的扩展，只是扩展的方向不同而已。VIPER把视图和数据拆得过细变相增加了复杂度很多人也都不熟也没有意愿去了解它的实现，但是模块复用却达到了最优，MVCS是这几个里对MVC优化最简单的只是把数据的存储拆开了。MVVM正好介于VIPER和MVCS之间，从ViewController里拆出来的ViewModel能够将数据经过逻辑处理用于View的显示，View有操作用过ReactiveCocoa将信号传给ViewModel来处理。

如果是我个人选择我会选择VIPER，因为它更符合细粒度模块划分的思想。但是用在团队多人开发上，还是偏向MVVM这种折中方案。MVVM按照先前对应用的结构分层，会将View和ViewController放到展现层的最下面的两层里，将ViewModel和Model放到基础层对应模块的最下面一层中。最后要说的是无论选择哪种，只要是按照减少ViewController大小，将改胖的地方放到Model或View都是可以的，招式学多后最高境界就是无招胜有招嘛，有时也不需要刻板的在一个项目中将所有的模块都按照统一的思路给框死，比如说一个模块很简单就用MVC，一般复杂就用MVVM，要是项目本身业务非常庞大可以整体采用VIPER来进行ViewController的完全拆分。

可以通过下列图表看其中的不同：