架构方案 MVC Model 数据模型，处理一些数据逻辑。 View 一些UI页面模块，依靠model展示数据 Controller 管理view和model 。包括请求数据，处理model逻辑，通知view的更新逻辑等 等 优点： 简单和常规页面很适合，开发成本低 缺点： 复杂页面场景，控制器的逻辑越发复杂，维护难度加大，同时，控制器还承担网 络请求的逻辑 MVVM Model 单纯数据模型，简单的适配逻辑等等 View 页面UI布局逻辑，依赖VIewModel展示数据 VM通知View更新，同时View告知VM状态，由VM来更新model数据，通知控制 器 Controller 调度View和VM，以及其它控制器直接操作 ViewModel 管理view数据，并包含model模型。数据的更新会通知到view 和控制器。 另外，根据业务，可以单独创建一个请求相关的ViewModel，管理这网络请求， 比如NetWorkManager 等等，把控制器这部分抽过来。 通知方式 RAC，delegate，Notification 优点 层次更明晰，职责更明确 耦合度更低，测试性更高，更便于单元测试 复用性更高，学习成本不高，MVC基础上抽离 缺点 常规MVVM是View和Model互补相连的，这在一定程度上给VM带来一些胶水代 码 MVP Presenter 负责调度View和Model，更新等等 Passive View Controller被弱化成为空壳子，重心是View Model 数据模型，逻辑处理，请求等等管理 优点 展示app组装展示特性，使得页面布局更为灵活 解耦。 对view和model解耦合 可测试性：视图拆分清楚测试业务清新方便 易用，本质上优化MVC的控制器调度，变化不大 结构示例 APP 主工程 壳工程，主工程的一些配置 脚本等等 Pods 业务组件Module 业务组件 公共业务组件 业务模块功能组件 lib 功能模块lib Utils Lib Router Lib 等等 三方库 基础库 基础功能库，最底层 Controller Factorys Sections DataManager 请求等数据来源 Model 解析模型 Utils 工具，逻辑等封装等等 CellRow TableRow 执行cell的刷新 view变化回调 CellView cell的展示布局 Model（解析模型） 职责 Controller 管理&组装模块 Factory 管理模块内Cell模块 每个页面都是tableView，都是以Cell形式展示 事件传递，回调等等 主要是block形式 Section Manager的管理者，负责将View，Data，Tool 等管理者集中调度。 TableRow cell模块管理者，负责view和model调度。更新及回调等等 CellView 负责Cell布局，以及展示model数据，并回调 Model 数据模型 DataManager 网络请求及数据转模型 库 Utils 工具 Router 路由解析&调度库