Models:跟数据相关的层,包括作为数据结构的 model,以及处理数据的逻辑。比如 Person 或者 PersonDataProvider 这样的类
Views:负责 UI 展示,在 iOS 中一般就是以 UI 开头的那些类
Controller/Presenter/ViewModel :作为 view 和 model 之间的桥梁,当 model 数据发生改变时,反馈变化到 view 的展示上,当响应用户在 view 层的交互操作时,同步修改 model 层的数据。
(读者注:处理数据的实体也能叫 model 层吗?viewController 算不算 view 层?)
这样划分的好处显而易见:
易于理解
易于复用(主要是 view 和 model)
方便独立测试
2. MVC
2.1 标准的 MVC
View 是无界限的,当 model 发生改变时,controller 就会重新渲染 View,就像点击网页上的链接时
reload 的过程一样
尽管可以在 iOS 上应用,但是并没有什么意义
M、V 和 C 层都紧密地耦合在了一起,任何一方都知道另外两方
复用性差
Traditional MVC doesn't seems to be applicable to modern iOS development.
2.2 Apple 的 MVC
理想
Controller 作为 View 和 Model 之间的中间者,这样 View 和 Model 就不需要知道对方了
可测性(Testability):View Model 不知道 View,所以 ViewModel 测试起来很简单。View 也可以测试,但是由于它依赖于 UIKit,所以我们一般会跳过。
可用性(Ease of use):因为有了绑定机制,所以相比 MVP,使用 MVVM 实现同样的功能可以少些很多胶水代码。另外,同样由于绑定,我们在调试时会更有难度。如果采用了函数响应式编程的思想,在学习成本上也会增加。
The MVVM is very attractive, since it combines benefits of the aforementioned approaches, and, in addition, it doesn’t require extra code for the View updates due to the bindings on the View side. Nevertheless, testability is still on a good level.
读『 iOS Architecture Patterns: Demystifying MVC, MVP, MVVM and VIPER 』
一、引言
当我们面对架构时经常会遇到这样一些问题:
上面提到的都是些方向性的问题,也许你还有些其他更急切、更实际的问题要解决:
二、为什么要架构选型
1. 为什么要架构选型
因为如果你不考虑架构的话,很有可能就会面临这样一个问题,在一个包含各种逻辑的庞大的类中查找问题、进行调试,你会发现你根本就没法搞清楚这个类到底是干什么的,也难以把这个类当成一个独立的实体看待。实际情况很有可能是这样的:
让人感到困扰的是,Apple 的 MVC 并不能解决上面的这些问题。
2. 好的架构应该是什么样的
三、MV(X)
1. MV(X)
现在我们常见的几种架构设计模式有:
前三种架构模式的一个共同点,就是把各个实体分为 3 类:
Person
或者PersonDataProvider
这样的类UI
开头的那些类这样划分的好处显而易见:
2. MVC
2.1 标准的 MVC
2.2 Apple 的 MVC
理想
Controller 作为 View 和 Model 之间的中间者,这样 View 和 Model 就不需要知道对方了
现实
根源:正是 Cocoa MVC 促使你们写成了 Massive View Controller,因为 ViewController 管理着 View 的生命周期。
问题:虽然有些逻辑可以转移到 Model 层,但是 View 层相关的逻辑就无能为力了,View 一般会把事件交给 Controller 处理
现状:Controller 负责的任务就多了,实现 delegate 和 data source 方法,负责网络请求相关的逻辑,上下拉刷新……
向现实妥协的 MVC:
单元测试:View 和 Controller 之间的通信不适合测试
回顾:对于小项目来说,也许你不需要考虑太多的架构问题,而且你也不希望有较高的维护成本,那么 Cocoa MVC 正好合适
3. MVP
3.1 MVP 与 MVC 的比较:
MVP 和 MVC 最大的不同在于,MVC 的 View 和 Controller 严重耦合,而 MVP 的中间者 Presenter 跟 view controller 的生命周期没有半点关系,Presenter 中也没有 view 布局相关的代码,Presenter 只负责根据数据变化更新 View,以及处理 View 的事件
3.2 MVP 的特点:
3.3 MVP 的问题(Router):
3.4 MVP 的变种:绑定和信号
4. MVVM:MV(X) 家族中最伟大的新生儿
4.1 MVVM 与 MVP 的比较
4.2 View Model 是什么
4.3 绑定
4.4 MVVM 的特点
5. VIPER
5.1 职能划分
5.2 VIPER 与 MV(X) 相比有什么不同
5.3 VIPER 的特点
四、结论