先放张图, 能完全看懂的基本就是老鸟,不用浪费时间继续看下去了.
MVC本质上是把对象划分为三大集中营(camps)- 模型(model),控制器(controller),视图(view). 主要是讲各三者之间如何通信 .
model - 你的应用是什么(但不管它是如何展示出来的).
controller - 控制model 在屏幕上的展示 方式
view - 展示界面.
图中间 两虚线 是指 controller可以直接调用(talk to) view 和model, 上面两侧的实线表示 model & view 不能直接调用 controller.下方两条黄线则表示, model是完全独立于View的, 严格意义上的MVC不允许 model和view之间通信, "分工明确,降低耦合" .
-
View 不能直接调用controller, 那如何实现信息传递呢? 通过一种盲目简单结构化的方式实现. V不需要知道C 具体是哪一种controller,里面包含什么 . 只需要像打靶(target)一样把接收到的用户屏幕交互信息(action)投射到目标控制器.
2.1 而当视图需要同步到控制器时, 就会采取代理(delegate)的方式( 如控制器生命周期方法 (-view Will/Should/Did Appear:)&(-view Will/Should/Did Disappear :) 就是view 的代理方法,在controller中实现). view不能持有它们所展示的数据,当数据量比较大时,就有了一种特殊的代理(delegate)- 数据源(dataSource),它更侧重数量上的表达. 如tableView,和collectionView都有各自的dataSource.
model 不知道控制的任何信息, 但是控制器需要实时监控哪些model数据发生了变化. 那model 是如何传递信息到controller的呢? 原来model 使用了一种
类似无线电广播站的广播机制, 用通知(notification)和KVO的方法, 将自身变化传递给任何一个想"收听(tune in)"的接收者--控制器或者其他model. 可能有人会说, 如果View也"收听"到了呢?理论上这是可以,但是这就违背了MVC初始的概念(隔离model和view,降耦合) . 所以当某某面试官问到你 , model 和view之间能不能通信时,那就可以这样说,理论上 通知和观察者可以实现(view监听model), 但是违背了MVC的初衷.MVCS, 在实际中大型项目中, 我们的项目结构里面是由多个MVC模型组成, 他们之间在一种低耦合的前提下协同工作.这也可以从主流的两种编码风格中看出, 一种是用单例模式创建一个可在多个controllers 间复用的 model(如全局用户信息, 全局的网络管理层). 一种就是tabbarController , 它就像一个容器, 每个item 包含了一个MVC模型, 组合起来就是MVCS. 从这种角度来看项目,整体思路也会更加清晰.
