给Controller减负

三层架构

• 给Controller减负，最先要考虑的是架构分层。平时简单的demo，业务不复杂，从界面到数据，Controller一个足够 了。但是实际项目中，不分层的项目到最后都会显得过于复杂。

• 没有架构，不行；层数太多了，也不好，接口增加，转接也麻烦。长期实践下来，分三层比较好。抽象出“组件”，“服务”两层，从功能和业务两个角度，将一些常用的内容抽象出来，进行复用。

• 为了使用方便使用，“组件”，“服务”两层的对外接口，可以统一为类的静态函数。

故事版

• 三层结构，最顶层的就是“模块”层，每个模块，可以用一个故事版来对应。

• 故事版中，每一个scene对应的是一个Controller；而Controller包含一个self.view；这样就把Controller和View柔和在一起了。

• 故事版可以通过一个Navigation Controller，将多个场景联系起来，更能体现模块内部的紧密联系。

• 两三个场景scene就可以成为一个独立模块，甚至一个也可以。最好不要超过5个，否则，就可以考虑继续拆分。

• 比如下面就是2个scene组成的一个模块，页面少，用起来比较灵活。

image.png

View

• 故事版，适合作为模块封装工具，整体进行链接和复用。不过，作为“组件”模式的块状复用，view更加好。

• 虽然故事版有container和child Controller的概念。经过实际体验之后，感觉还是直接使用view更方便。

• 故事版和view是不同的，另外view的文件后缀是xib，不过跟以前的xib也是两回事。以前的xib，更确切地说是Controller，而不是view

image.png

• 故事版和view，本质上都是xml，当然可以给Controller减负。

• 代码写界面，那么Controller就相当于一个容器，具体的视图可以分解到各个view中，也可以给Controller减负。

ViewModel

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中代码多一点感觉无所谓的，就没有必要增加文件了。

小结

• 使用故事版，可以减少代码，同时也给Controller减负，这个支持；

• 使用View，不管是用xib还是用代码写view，可以给Controller减负，支持，并且也更容易复用。

• 抽象出组件层和服务层，增加复用，同时也给Controller减负，强烈支持

• ReactiveObjC推荐引入，可以让Object-C更像JS，可以带来很多方便

• ViewModel看具体情况引入。毕竟要增加文件，增加转接，还是看团队习惯吧