三层架构
给
Controller减负，最先要考虑的是架构分层。平时简单的demo，业务不复杂，从界面到数据，Controller一个足够 了。但是实际项目中，不分层的项目到最后都会显得过于复杂。没有架构，不行；层数太多了，也不好，接口增加，转接也麻烦。长期实践下来，分三层比较好。抽象出“组件”，“服务”两层，从功能和业务两个角度，将一些常用的内容抽象出来，进行复用。
为了使用方便使用，“组件”，“服务”两层的对外接口，可以统一为类的静态函数。
故事版
三层结构，最顶层的就是“模块”层，每个模块，可以用一个故事版来对应。
故事版中，每一个
scene对应的是一个Controller；而Controller包含一个self.view；这样就把Controller和View柔和在一起了。故事版可以通过一个
Navigation Controller，将多个场景联系起来，更能体现模块内部的紧密联系。两三个场景
scene就可以成为一个独立模块，甚至一个也可以。最好不要超过5个，否则，就可以考虑继续拆分。比如下面就是2个
scene组成的一个模块，页面少，用起来比较灵活。
View
故事版，适合作为模块封装工具，整体进行链接和复用。不过，作为“组件”模式的块状复用，
view更加好。虽然故事版有
container和child Controller的概念。经过实际体验之后，感觉还是直接使用view更方便。故事版和
view是不同的，另外view的文件后缀是xib，不过跟以前的xib也是两回事。以前的xib，更确切地说是Controller，而不是view
故事版和
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看具体情况引入。毕竟要增加文件，增加转接，还是看团队习惯吧
