起因
后段微服务重构，前端配合2.0。
本人对微服务略知一二，所以不多阐述。对应到前端所要做的，即每个小的模块对应一个服务项目，并且模块的扩展性随服务的扩展性增加而增加，单个小模块的问题不导致整个系统的崩溃。减少测试成本，降低维护难度。
考虑
因为是模块化，每个模块的灵活度有服务端来提供。在mvc模式下，controller的代码量会随之增加。为了减轻controller的代码量，进行vc切割。可以采用VIPER模式的思想，将controller 拆分成router和presenter。即presenter负责处理model，并和view进行交互。router负责将各模块衔接在一起，同时负责页面的跳转部分。Entity和Interactor负责model部分。原来的model部分也是将model部分拆分成，网络数据调用、解析和数据存储这两部分，在此就不需要更加细化的拆分。
具体案例分析：
这里采用b站iOSApp作为案例。
b站的app细看下是有好多模块组成的，各种数据也是从后台得到的。同时后台也采用了微服务的设计。
对于上面的页面，用VIPER划分6个view、6个presenter 、1个router、1个entity和6个interactor。即nagivation，关注娱乐的自导航栏，轮播collectionview，明星直播view ，推荐主播collectionview 和下面的tabbar。将这些页面拼凑到router中统计一的调度，各个业务逻辑分写到presenter中，这样整个controller的代码将缩减很多，且业务逻辑分离。这在测试和维护的时候将省去很多问题。
对于多人合作上的问题。就上述划分，有许多东西也很多复用价值。在多人合作上，如果有复用的，单个人只要重写presenter和router，至于interactor和entity可以稍作修改或增加，这样可以保证整体代码样式的规范性，在测试和维护上减少成本。但也有对整个架构不熟悉的开发者，这样就会写出冗余的代码。
弊端分析：由于差分的细化。如果结构层次过深，横向过长。这样对于新的开发者不友好。而且有第三方团队的参与的话，很有可能有冗余代码的产生。
总结
运用VIPER架设模块化应用并非最好的模式，正如我同事所说，一切还要靠开发者。就像建造房子一样，设计很好，但施工方偷工减料。这样问题也不少。但是运用VIPER架构可以做到那坏换哪的方式，细化的拆分带来的测试和维护成本减少也将有利于一个大工程的构建。
