深入浅出MVC模式

来源：互联网发布：中国象棋软件哪个好使编辑：程序博客网时间：2024/06/05 07:50

写在前面：这是一篇纯理论的文章，深入浅出的讲解一些我在学习斯坦福公开课时理解的MVC模型，它绝不是单纯的翻译其中的内容，这是笔者将他讲解的内容通过自己理解过滤后一字字码出来的，具有很强的逻辑性，以便让大家以及我自己在今后更好的去理解

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑（来自百度百科）

简介

MVC是一个基本模型，用于分类程序中的所有对象到三个阵营中的任意一个。

模型（Model）
Model = What your application is (but not how it is displayed)
模型（Model)，模型层是程序的行为的合集
视图（View）
View = Your Controller’s minions
视图（View），视图层是控制器（Controller）的辅助类，我们在构建我们的界面时会用到它，在视图（View）中的内容是相当通用的界面元素
控制器（Controller）
Controller = How your Model is presented to the user(UIlogic)
控制器（Controller），控制器（Controller）的作用给View解释并格式化这些来自模型（Model）的数据

通信

正确的MVC不仅仅知道内容的存放位置而且需要知道三层是如何通信的，接下来我们总结一下这三层是如何通信的。
（双黄线和白色虚线表示通信方式）

控制器与模型的通信：

1. 控制器（Controller） -> 模型（Model）：完全控制权

Controller可以了解Model的一切行为，并且必须完全有能力与Model通信，根据Controller的需求使用Model公开的接口（API），因为Controller的职责就是通过View想用户展示Model中的数据，因此Controller拥有完全控制权限可以与Model通信。

2. 模型（Model） -> 控制器（Controller）：Notification（通知）和KVO（键值对观察）

通常情况下，Model是不能与Controller通信。
场景：Model中的数据发生了变化，而Controller需要知道这种变化，如：数据改变了，数据库改变了。
问题：Model如何与Controller通信告诉他这些变化？
答案：Model会用一种电台的概念，将信息广播给想知道的任何Controller，在IOS中这种技术叫做Notification（通知）和KVO（键值对观察），所以Model的任务就是当数据发生变化是，通过Notification（通知）和KVO（键值对观察）广播一下，随后Controller会接收到来自广播的信息，他会发现数据在变化，他会再与Model通信获取改变后的数据

控制器与视图的通信

1. 控制器 -> 视图：完全控制权

Controller是可以访问View的，因为控制器负责通过自身对象向View发送指令，View是Controller向用户展示界面的一种方式，因此Controller可以控制View做任何它想做的事，这里会提到Outlet的概念（Outlet是控制器的一个属性，用于指向视图）。我们创建一个Outlet实际上就是实例化一个View到Controller中，这样我们的Controller可以发送指令到对应View了
Swift
1
2
3
class DemoViewController: UIViewController {
@IBOutlet weak var table: UITableView!
}
如上代码：UITableView作为一个视图，table即Outlet（DemoViewController的一个指向UITableView的属性），这样DemoViewController就具有了对UITableView的控制权了

2. 视图 -> 控制器：代理（Delegate）和数据源（DataSource）

因为View是通用的，他们不能真正的了解调用它们的Controller，所以他们只能盲目的方式与Controller通信
问题：视图上有个按钮（UIButton）它能跟Controller通信吗？
答案：可以，但是要注意，因为View是通用的，他们不能真正的了解调用它们的Controller，所以他们只能盲目的方式与Controller通信。一种大家都认同的，View与Controller通信的方式（Target操作和代理）
方式一： addTarget操作
控制器（Controller）本身写一个目标方法（target），然后给View的行为方法（action），并告诉View当你想做执行操作（比如你是一个按钮被点击，或者滑动条被滑动）给控制器（Controller），你可以通过此行为方法（action）向Controller发送消息，通过这种方式，通用的按钮或者拖动条就可以反过来与Controller通信了，它根本不需要知道调用的它控制器到底是什么类型的Controller，他只需要知道某一个事件在他身上触发时他就要通过行为方法（action）想目标方法（target）发送一个消息，就是这样一个盲目的、简单的、结构化的方式来作为视图与控制器之间的通信。还是代码比较直观`(∩_∩)′
Swift
1
2
3
4
5
6
7
8
9
    classDemoViewController: UIViewController{
        @IBOutletweakvarbtn:UIButton!
        overridefuncviewDidLoad(){
            btn.addTarget(self,action:"hello:",forControlEvents:.TouchUpInside)
        }
        funchello(){
            print("Hello World!"
        }
    }
这样是不是很好理解：在DemoViewController中添加一个target：hello(),然后通过addTarget给View对象btn添加action。当你点击按钮时，就是打印：Hello World！
方式二：代理（Delegate）和数据源（DataSource）
代理（Delegate）：
假如有时发生在视图（View）上的事件是比较复杂的，理解这个的方法是我通过几个关键字（will、should、did）描述这些情况：
假如我们的View是一个滚动视图（ScrollView），用户按住它，将要滑动，它想要Controller知道用户将要执行滑动操作（will）
假如它正在滚动，并且它想让Controller知道用户刚刚做了滚动操作（did）
又或者用户按住屏幕滚动视图（ScrollView）需要知道是否允许这里执行滚动操作（should）
所有这些情况，滚动视图（ScrollView）本身或许没有足够的逻辑知道那些问题的答案，那它需要做的就是代理给Controller对象来回答这些问题（will，should，did，this，that或者其他事情例如：允许滑动、滑动到一点等等等…），你将要在那些代理协议中看到他们。这里我们需要在控制器中代理这些协议（盲目通信）
依旧是代码才会有更好的直观性，还记得在我们文章（一）和文章（二）需要给UITableView做代理吗？其实我介绍了两种方式，我更偏向第二种：拓展方式，代码逻辑更清晰
Swift
1
2
3
4
5
6
7
8
9
10
11
extension DemoViewController: UITableViewDelegate {
    func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath)
    {
        let index = indexPath.row
        let string = self.dataList[index]
        if let closure = self.myClosure {
            closure(tag: self.myTag!,string: string)
        }
        self.dismissViewControllerAnimated(true, completion: nil)
    }
}
上述代码：控制器：DemoViewController代理了视图UITableView的didSelectRowAtIndexPath协议，告诉视图我选中了某一行时需要执行的操作。
数据源（DataSource）：
视图（View）不应该持有展示他们的数据，如果持有数据就违背了视图（View）的通用性了，换句话说：数据不应该作为视图的内部属性。
场景：例如你要展示iPhone上的所有歌曲，你可能有10000首歌曲，另外你有一些通用的视图列表在你的视图（View）中，你不能传递这10000首歌给他实例变量中，并期望它来持有10000首歌以便你去浏览他们。
原因：
– 这种方式不高效；
– 这10000首歌属于哪一层？应该是Model。
你的音乐数据库本身就是一个Model（它与UI无关），视图仅仅是歌曲、艺术家、专辑和其他信息的一个列表，Controller必须通过Model查询数据并告诉一个View如何展示这些歌曲，所以我们需要通信让View展示数据，这些通信如何发生？答案：使用另一个种特殊的代理——数据源（DataSource），数据源不做之前代理（will、should、did……）的事。数据源（DataSource）做类似：数量：（有多少首歌曲），Controller查找Model将10000返回给视图，然后视图（View）为这些歌曲开辟内部空间。
当你在底部滚动它，他就开始发消息给控制器加载10条记录（返回150行后面的10条数据），控制器再次跟Model通信，并获取接下来的10条数据，于是控制器（Controller）通过这种盲目方式提供数据给视图，这就是视图（View）如何通过Model得到数据是通过这种不明确的、没有针对性的、结构化的方式。
所以数据源（DataSource)就是一个特殊类型的用于获取数据的代理，像列表视图（UITableView）他就有一个数据源和一个通常的代理
依旧是代码：上面我们给UITableView做了代理，接下来我们为UITableView绑定数据源
Swift
1
2
3
4
5
6
7
8
9
10
11
12
13
14
extensionDemoViewController: UITableViewDataSource{
    funcnumberOfSectionsInTableView(tableView:UITableView)->Int{
        return1
    }
    functableView(tableView:UITableView,numberOfRowsInSectionsection:Int)->Int{
        returnself.dataList.count
    }
    functableView(tableView:UITableView,cellForRowAtIndexPathindexPath:NSIndexPath)->UITableViewCell{
        letcell=tableView.dequeueReusableCellWithIdentifier(self.cellId,forIndexPath:indexPath)as!DemoListCell
        //cell.cellImg.image = UIImage(named: powerData[indexPath.row][2])
        cell.cellLabel.text=self.dataList[indexPath.row]
        returncell
    }
}

总结：OK！这就是View: UITableView跟控制器（Controller）的通过一种不明确的结构化方式：分为代理（Delegate）和数据源（DataSource)

模型与视图的通信：不能（Never）

很明显，模型（Model）是完全独立于UI的，模型没有任何办法向视图对象发送只送指令，也不能和视图层的任何对象通信，因为视图对象是基本的UI对象，他们是某种程度上是通用的，但是也是基本的UI对象，既然视图对象是通用的对象，他们就不能和任何特定的Model对象通信，他们需要一个控制器来传达信息。一句话：模型（Model）与视图（View）之间在没有任何通信

重要体会：

最后你会体会到，IOS开发框架本就是MVC模式，我们常用的控件无一不是视图，我们创建的ViewController其实都是控制器，我们实例化一个控件，就是为我们的Controller创建一个Outlet，并对其显示和控制，说到Model，CoreData就是我们的Model，原来我们一直都在MVC的世界里摸索到底什么才是MVC，多么痛的领悟！

名词解释：

M（Model）:模型
V（View）：视图
C（Controller）：控制器
Outlet ：控制器指向视图的属性
Notification：通知
KVO（Key-Value Observing）：键值对观察
Delegate：代理，视图向控制器通信，通过 will、should、did等方式统称为代理
DataSource：数据源，一种特殊类型的代理，取决于视图是否需要显示大量数据
protocol：协议，在编程中含义：我的理解通过一种盲目（Blind）的、没有针对性的方式与其他对象通信。

如果是一个比较大型的复杂的项目呢？在屏幕上有三四个不同的区域都在发生着什么，我们可以结合多个MVC

from: http://ios.jobbole.com/84175/

0 0