1.MVC
M
数据类，数据请求和处理的。
class M {
var name:String?
func netWorking() {
//网络请求
}
}
V
View类，数据展示和页面处理。
class V {
var nameLabel?
}
C
Controller类，M 和 V 的中间人
class C {
//实例化 M V
let m = M()
let v = V()
//to do something
m.netWorking
v.nameLabel.text = m.name
}
MVC这种模式很简单和易于理解，中型不太复杂和小型项目使用非常方便。开发快速。但是如果稍微复杂一点话 C 里面的代码就很多，不利于后续开发和维护。
2.MVP
M
数据M类，数据请求和处理的。
class M {
var name:String?
func netWorking() {
//网络请求
}
}
V
View类，数据展示和页面处理。
class V {
var nameLabel?
}
P
Presenter类，M 和 V 的中间人
class P {
var v: V?
var m: M?
func loadData(){
//to do something
v.nameLabel.text = m.name
}
}
C
Controller类
class C {
//实例化 M V P
let m = M()
let v = V()
let p = p()
//to do something
p.v = v
p.m = m
m.netWorking
p.loadData()
}
MVP这种模式输入MVC的进化版本，大家可看到我吧每个都说成是一个类（数据M类,View类,Presenter类）.
这个思想很重要，有了类的思考，后续的开发和学习才会变得更好理解。
Controller 由于是显示当前屏幕，在很开始学习的时候我并没有把C当做类，很普通的类看待，所以才会在C中一值写代码不可自拔。
P 成出生就是一个很普通类，但是我们赋予了他不一样的力量。他成了C的左右手.再复杂C,再来几个P
3.MVVM
M
数据M类，数据请求和处理的。
class M {
var vm:VM?
func netWorking() {
//网络请求
vm = result
}
}
V
View类，数据展示和页面处理。
class V {
var vm:VM?
var nameLabel?
}
VM
VM类, view_model 针对V类需要的数据字段
class VM {
var name: String?
}
C
Controller类
class C {
//实例化 M V VM
let m = M()
let v = V()
//to do something
m.netWorking
v.vm = m.vm
}
这样大家可以看到明显的区别了，MVP是吧MV的交互放到P里面。
也就是说 MVC，MVP的思考方式是，M 和 V的交互放在那里去处理，本质没有区别。
可以这么形容一下
MVC 是一个中央集市，无论我业务量量多大都要在C 中去完成交易处理，没有负责人概念，想和谁完成交易自己去找，又累又麻烦。
MVP是一个大集市中多个分区，这些分区负责C中的不同区域，划分明确。但是在这些分区中，依然存在问题想和谁完成交易还得自己去找，还是很麻烦。观念老旧。
MVVM 多了一个VM(view_model),这就延伸出一个新的概念，数据流。
相当是一种游戏的任务清单，接受任务，执行任务，完成任务。完全由猎人（view）自己决定接受什么样的任务（加载怎样的数据view_model）。
在一个大集市中流淌着各种买卖信息，买的人发送买东西的信息，卖的人接受符合自己交易，完成买卖。view_model 就是一个链条，连接彼此。就像一个互联网完成线上交易。
MVVM更现代，更高效，更漂亮。
网友评论