设为首页 加入收藏

TOP

MVC和MVVM详解(一)
2016-07-13 22:02:58 】 浏览:970
Tags:MVC MVVM 详解

前言

请预留足够的时间,您将看到大量的文字描述。但是相信我,您绝对值得花时间在这些文字描述上面。我已经尽了我最大所能来阐述关于MVC和MVVM如此这般设计的原因以及我们应该如何思考一些相关的问题

让我们从MVC开始

说起MVC,必须拿斯坦福大学公开课上的这幅图来说明,这可以说是最经典和最规范的MVC标准

MVC

所以看懂这张图,你就应该明白MVC在iOS中的实现思路了。

你一直在使用MVC的思想只是你可能没有察觉到

在我们着手探究MVC之前,有些东西是你应该了解的,虽然你可能已经了解了,但是这里还是要拿出来说一下,因为这些内容对于你理解MVC是如何运作的有很大的帮助。
几乎所有的App都只干这么一件事:将数据展示给用户看,并处理用户对界面的操作。
写过iOS App开发的开发者都知道我们大量的操作都是在controller中写布局代码再把数据显示到视图上面,然后实现一些专门处理用户操作的逻辑(比如按钮点击事件的实现)。
这里实际上你已经无形之中使用了MVC的思想了:一句话描述就是Controller负责将Model的数据用View显示出来,换句话说就是在Controller里面把Model的数据赋值给View,比如在controller中写self.label.text = self.data[@”title”],只是还没有刻意建一个Model类出来而已。

MVC是如何进行工作的

简(xiang)单(xi)解释一下MVC所代表的意思(网上随处可见)

M:Model,数据模型,比如我们人类有一双手,一双眼睛,一个脑袋,没有尾巴,这就是模型,Model定义了这个模块的数据模型。在代码中体现为数据管理者,Model负责对数据进行获取及存放。数据不可能凭空生成的,要么是从服务器上面获取到的数据,要么是本地数据库中的数据,也有可能是用户在UI上填写的表单即将上传到服务器上面存放,所以需要有数据来源。既然Model是数据管理者,则自然由它来负责获取数据。Controller不需要关心Model是如何拿到数据的,只管调用就行了。数据存放的地方是在Model,而使用数据的地方是在Controller,所以Model应该提供接口供controller访问其存放的数据(通常通过.h里面的只读属性)。

V:View,视图,简单来说,就是我们在界面上看见的一切。大多数情况都是继承自UIView的类的对象,而有时候则不是直接继承自UIView,有时候会直接用CoreAnimation甚至CoreGraphics来绘制内容,但这些东西统统都归结为MVC中的View。它们有一部分是我们UI定死的,也就是不会根据数据来更新显示的,比如一些Logo图片啊,这里有个按钮啊,那里有个输入框啊,一些显示特定内容的label啊等等;有一部分是会根据数据来显示内容的,比如tableView来显示好友列表啊,这个tableView的显示内容肯定是根据数据来显示的。我们使用MVC解决问题的时候,通常是解决这些根据数据来显示内容的视图。这里要提个醒:MVC虽然看似把模块分为了三部分,但是并不是说一个模块就要一定建三个类出来,比如联系人列表(ContactsList)模块,一定会有的肯定是ContactsListViewController,然后我们使用MVC来作为内部的框架,则需要创建ContactsListModel类,接下来会有少年继续创建ContactsListView,他认为这才是MVC,有三个类分别是XXXModel、XXXController、XXXView,这就大错特错了,你们在Controller中使用的UILabel、UITableView等等就是MVC中的View了,不要再专门建一个XXXXView出来,完全是没事找事多此一举。

C:Controller,最熟悉却又最抽象的一个东西。之所以熟悉,我们在使用UIKit进行开发中我敢说是你打交道最多的类:UIViewController。UIKit框架离不开UIViewController,当然你完全可以使用UIView来完成所有本该由Controller完成的事情,这是大逆不道的,因为这样做将会使你的整个项目代码一团糟,并且完美的违背了面向对象的思想:各司其职。这里大家一定要知道UIViewController究竟应该做些什么事,实际上就是API提供出来的接口:self.view用来作为所有视图的容器;管理自己的生命周期;controller之间的转场;controller容器。这是Controller的本职工作,然而它往往还需要承担起MVC中的数据和视图的协调者,也就是在Controller里面把Model的数据赋值给View来显示(或者是View接收用户输入的数据然后由Controller把这些数据传给Model来保存到本地或者上传到服务器)。

综合以上内容,实际上你应该可以通过面向对象的基本思想来推导出controller出现的原因:我们所有的App都是界面和数据的交互,所以需要类来进行界面的绘制,于是出现了View,需要类来管理数据于是出现了Model。我们设计的View应该能显示任意的内容比如UILabel显示的文字应该是任意的而不只是某个特定Model的内容,所以我们不应该在View的实现中去写和Model相关的任何代码,如果这样做了,那么View的可扩展性就相当低了。而Model只是负责处理数据的,它根本不知道数据到时候会拿去干啥,可能拿去作为算法噼里啪啦去了,可能拿去显示给用户了,它既然无法接收用户的交互,它就不应该去管和视图相关的任何信息,所以Model中不应该写任何View相关代码。然而我们的数据和界面应该同步,也就是一定要有个地方要把Model的数据赋值给View,而Model内部和View的内部都不可能去写这样的代码,所以只能新创造一个类出来了,取名为Controller。它被UIKit逐渐完善成了我们现在使用的UIViewController。

看图说话

你要问我以上这么一大堆东西我是怎么知道的?我就完成了一次看图说话而已,我们终于要开始讲解这张图了,为了更好的观看体验,我再次向您呈现出这张图,这样你就不需要往上面翻一大段内容了。

MVC

duang!

废话不多说了,这张图把MVC分为三个独立的区域,并且中间用了一些线来隔开。很有意思的设计,因为这些线似乎出现在了驾校科目一的内容中,你瞧C和V以及C和M之间的白线,一部分是虚线一部分是实线对吧,这就表明了引用关系:C可以直接引用V和M,而V和M不能直接引用C,至少你不能显式的在V和M的代码中去写和C相关的任何代码,而V和M之间则是双黄线,没错,它们俩谁也不能引用谁,你既不能在M里面写V,也不能在V里面写M。哦,上面的描述有点小小的问题,你不是“不能”这样写,而是“不应该”这样写,没人能阻止你在写代码的时候在一个M里面去写V,但是一旦你这样做了,那么你就违背了MVC的规范,你就不是在使用MVC了,所以这算是MVC的一个必要条件:使用MVC –> M里面没有V的代码。所以M里面没有V的代码就是使用MVC的必要条件,如果P->Q,那么~Q->~P,初中还是高中数学讲过吧,如果你在M里面写了V的代码,那么你就不是在使用MVC

首页 上一页 1 2 下一页 尾页 1/2/2
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇图解VC++版PE文件解析器源码分析 下一篇面试之路(3)-详解MVC,MVP,MVVM

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容:

最新文章

热门文章

C 语言

C++基础

windows编程基础

linux编程基础

C/C++面试题目