在介绍应用架构之前,先来看看目前iOS上最基础的架构MVC,以及为解决MVC的毛病而诞生的其他几个架构,如MVVM。
Cocoa的很多技术跟架构都是基于MVC。而且无论是文档、示例代码,还是创建一个项目时提供的模版代码,Apple都鼓励开发者去使用MVC。MVC定义了App里对象的角色(Model-View-Controller),以及它们之间的交互方式:
1、Model: 表示业务数据对象
2、View: 展示数据的UI
3、Controller: Model跟View之间的粘合剂。一方面对View上的行为作出反应,通常会涉及到Model的更改;另一方面将Model的改动反应到View上
由于Controller作为粘合剂的存在,View 和 Model 只需要跟 Controller 交互,而不知道另一方的存在。这样,View 和 Model 作为独立可复用的组件,Controller 里处理业务逻辑。听起来这样的架构很清晰直观,实际应用中,MVC 对于不是很复杂的 App 也是非常高效的。但对稍复杂些的App,MVC 使用起来就会非常吃力。
你可能听过 MVC 也被简称为 Massive View Controller,这就是原因所在 - View Controller 承担的责任太多:
1、网络请求
2、数据访问和存储
3、UI的调整和组合
4、业务逻辑
5、View 的 delegate、data source
6、状态的维护
与单一责任准则背道而驰。过于臃肿的 View Controller 使 App 的维护成本非常高。我们的第一个项目有数刚接手时就是这个样子,尽管我们已经把网络请求以及数据访问和存储放到了 Model 里,但由于对象边界的定义不够清晰,大部分 View Controller 依然很臃肿,上千行的 View Controller 很常见。 关于 View Controller 有个准则:如果一个 View Controller 超过了 300 行代码,那它一定做了责任范围以外的事。更不幸的是由于一些职责移交给 Model,导致 Model 也变得臃肿起来。原来唯一可以做 Unit Test 的 Model 现在测试也很困难。
为解决 MVC的问题,MVVM、VIPER等架构应运而生。
MVVM架构: MVVM的出现主要是为了解决在开发过程中 Controller 越来越庞大的问题,变得难以维护,所以 MVVM 把数据加工的任务从 Controller 中解放了出来,使得 Controller 只需要专注于数据调配的工作,ViewModel则去负责数据加工并通过通知机制让 View 响应 ViewModel 的改变。
MVVM是基于胖Model的架构思路建立的,然后在胖Model中拆分两部分:Model和ViewModel。 ViewModel 本质上算是Model层(因为是胖 Model 里面分出来的一部分),所以 View 并不适合直接持有 ViewModel,因为 ViewModel 有可能并不是只服务于特定的一个View,使用更加松散的绑定关系能够降低 ViewModel和View 之间的耦合度。
还有一个让人恨容易忽略的问题,大部分国外资料阐述MVVM的时候都是这样排布的:
1
|
ViewViewModel Model
|
造成了 MVVM 不需要 Controller 的错觉,现在似乎发展成业界开始出现 MVVM 是不需要 Controller 的声音了。其实 MVVM 是一定需要 Controller 的参与的,虽然 MVVM 在一定程度上落化了 Controller 的存在感,并且给 Controller 做了减负瘦身(这也是 MVVM 的主要目的)。但是,这并不代表 MVVM 中不需要 Controller, MMVC和MVVM他们之间的关系
应该是这样:
1
|
View C ViewModel Model
|
所以使用 MVVM 之后,就不需要 Controller 的说法是不正确的。严格来说 MVVM 其实是 MVCVM。从中可以得知,Controller夹在 View 和 ViewModel 之间做的其中一个主要事情就是将View和ViewModel进行绑定。在逻辑上,Controller 知道应当展示哪个View,Controller也知道应当使用那个 ViewModel,然而 View和ViewModel 它们之间是相互不知道的,所以 Controller 就负责控制他们的绑定关系,所以叫Controller/控制器就是这个原因。
前面扯了那么多,其实归根结底就是一句话:在MVC的基础上,把c拆出一个ViewModel专门负责数据处理的事情,就是 MVVM。然后,为了让 View 和 ViewModel 之间能够有比较松散的绑定关系,于是我们使用 ReactiveCocoa,KVO,Notification,block,delegate和target-action都可以用来做数据通信,从而来实现绑定,但都不如ReactiveCocoa提供的RACSignal来的优雅,如果不用ReactiveCocoa,绑定关系可能就做不到那么松散那么好,但并不影响它还是MVVM。
MVVM(View-ViewManger-C-ViewModel-Model)
1、View - 用来呈现用户界面
2、ViewManger - 用来处理 View 的常规事件,负责管理View
3、Controller - 负责 ViewManger和ViewModel 之间的绑定,负责控制器本身的生命周期。
4、ViewModel - 存放各种业务逻辑和网络请求
5、Model - 用来呈现数据
这种设计的目的是保持 View和Model 的高度纯洁,提高可扩展性和复用度。在日常开发中,ViewModel是为了拆分 Controller 业务逻辑而存在的,所以 ViewModel 需要提供公共的服务接口,以便于 Controller 提供数据。而 ViewManger 的作用相当于一个小管家,帮助 Controller 来分别管理每个 subView,ViewManger 负责接管来自 View 的事件,也负责接收来自 Controller 的模型数据,而 View 进行自己所负责的视图数据绑定工作。Controller 则是最后的大家长,负责将 ViewModel和ViewManger进行绑定,进行数据转发工作。把合适的数据模型分发给合适的视图管理者。