给Controller减负

三层架构

给Controller减负，最先要考虑的是架构分层。平时简单的demo，业务不复杂，从界面到数据，Controller一个足够了。但是实际项目中，不分层的项目到最后都会显得过于复杂。
没有架构，不行；层数太多了，也不好，接口增加，转接也麻烦。长期实践下来，分三层比较好。抽象出“组件”，“服务”两层，从功能和业务两个角度，将一些常用的内容抽象出来，进行复用。
为了使用方便使用，“组件”，“服务”两层的对外接口，可以统一为类的静态函数。

三层结构，最顶层的就是“模块”层，每个模块，可以用一个故事版来对应。
故事版中，每一个scene对应的是一个Controller；而Controller包含一个self.view；这样就把Controller和View柔和在一起了。
故事版可以通过一个Navigation Controller，将多个场景联系起来，更能体现模块内部的紧密联系。
两三个场景scene就可以成为一个独立模块，甚至一个也可以。最好不要超过5个，否则，就可以考虑继续拆分。
比如下面就是2个scene组成的一个模块，页面少，用起来比较灵活。

image.png

故事版，适合作为模块封装工具，整体进行链接和复用。不过，作为“组件”模式的块状复用，view更加好。
虽然故事版有container和child Controller的概念。经过实际体验之后，感觉还是直接使用view更方便。
故事版和view是不同的，另外view的文件后缀是xib，不过跟以前的xib也是两回事。以前的xib，更确切地说是Controller，而不是view

image.png

ViewModel是从Controller中分离出来的一层，是否引入存在很大的争议

将ViewModel当做Helper看待，可以引入。作为Controller的助手，可以分担Controller的一些工作，比如网络请求，数据处理，业务逻辑等等，从而给Controller减负
作为表格cell的数据接口，可以引入。将表格需要的界面展示信息集中起来，成为一个ViewModel，比一个个零散的参数方便多了- (void)updateWithViewModel:(xxxViewModel *)viewModel;。另外，如果遇到不同的Model展示相同的界面，只要多提供几个初始化函数就可以了。- (instance)initialWithModel:(xxxModel *)model;
对于组合型的复杂场景，可以引入。比如tab类型的页面，比如登录分为验证码和密码两种模式。这个时候Controller可以作为顶层管理者，引入几个ViewModel，分别处理不同的情况，整个情况就会清晰很多
替代childController。说实话，故事版关于segue相关的API不是很好用，引入的childController用起来也不方便。相关的功能不如用view或者ViewModel来替代更方便。
替换胖Model，比如网络访问放哪里？放Controller和Model中感觉都不合适，那么，引入一个ViewModel也是可以的

简单的页面就不要引入了
引入ViewModel，会增加文件个数，并且会增加调用层次
ReactiveObjC和ViewModel没有关系。不过ReactiveObjC的引入，对于简化调用关系还是很有帮助的。如果没有ReactiveObjC，ViewModel还是不引入的好。
对于Controller中代码多一点感觉无所谓的，就没有必要增加文件了。