iOS重构实践重构实践
项目简介和MVP模式重构
项目简介
首先简单介绍一下项目情况。我们原有项目的架构是比较标准的MVC模式,也是苹果官方推荐的架构模式。Model层用来表示
实体类,View层负责界面展示和传递UI事件,Controller层负责大部分的业务逻辑。除此之外,对一部分公共的可复用的逻
辑,我们抽象出Service层,提供给Controller使用,另外网络层也独立出来。下图比较清楚地展示了整体架构
整体架构
MVC模式的问题
MVC架构作为苹果官方推荐的架构模式,把数据Model和展现View通过Controller层隔离开,在项目规模较小的时候是一个不
错的选择。随着项目复杂性的提高,我们也渐渐感觉到MVC模式的弊端,主要体现在下面几个方面
Controller层职责过多,Model和View层太简单
Controller处理业务逻辑,处理UI更新,处理UI事件,同步Model层,我们几乎所有的代码都写在了Controller层。设计模式里
有单一模式原则,你看这里的Controller层已经至少有四种职责了。
业务逻辑和UI混杂在一起,难以编写单元测试
这一点一方面是因为Cocoa框架里的Controller层,就是我们最熟悉的UIViewController和View是天然耦合的,很多view的生命
周期方法如viewWillAppear都存在于VC,另一方面我们很多时候也习惯于把UI操作甚至初始化操作放在VC里,导致UI和业务
逻辑混杂在一起。当你想对业务逻辑编写单元测试的时候,看着业务逻辑代码里混杂的UI操作,就知道什么叫举步维艰——数
据可以Mock,UI是不可能被Mock的。
业务逻辑代码大量存在于Controller层,维护困难
当一个界面功能比较复杂的时候,我们所有的逻辑代码都会堆积在Controller中,比如我们原有的WebViewController的代码就
多达5000行,在这种情况下维护代码简直是如履薄冰。
MVP模式的重构
对于Controller层过于臃肿的问题,MVP模式则能较好地解决这个问题——既然UIViewController和UIView是耦合的,索性把
这两者都归为View层,业务逻辑则独立存在于Presenter层,Model层保持不变。下图比较清除得展示了MVP模式的结构