详解MVC,MVP,MVVM
mvc结构:
视图(View):用户界面。
控制器(Controller):业务逻辑
模型(Model):数据保存
mvc各部分的通信方式
mvc互动模式
通过 View 接受指令,传递给 Controller。
另一种是直接通过controller接受指令。
mvc的历史
MVC 的概念最早出现在二十世纪八十年代的 施乐帕克 实验室中(对,就是那个发明图形用户界面和鼠标的实验室),当时施乐帕克为 Smalltalk 发明了这种软件设计模式。
- 1
controller层的臃肿问题
于 View 来说,你如果抽象得好,那么一个 App 的动画效果可以很方便地移植到别的 App 上。
对于 Model 来说,它其实是用来存储业务的数据的,如果做得好,它也可以方便地复用。
如果我们能够意识到 Controller 里面的代码不便于复用,我们就能知道什么代码应该写在 Controller 里面了,那就是那些不能复用的代码。
一个解决的思路
Controller 里面就只应该存放这些不能复用的代码,这些代码
在初始化时,构造相应的 View 和 Model。
监听 Model 层的事件,将 Model 层的数据传递到 View 层。
监听 View 层的事件,并且将 View 层的事件转发到 Model 层。
- 1
- 2
- 3
Controller 只有以上的这些代码,那么它的逻辑将非常简单,而且也会非常短。
controller进一步的解决方案
但是,我们却很难做到这一点,因为还是有很多逻辑我们不知道写在哪里,于是就都写到了 Controller 中了,那我们接下来就看看其它逻辑应该写在哪里。
将 UITableView 的 Data Source 分离到另外一个类中。
将数据获取和转换的逻辑分别到另外一个类中。
将拼装控件的逻辑,分离到另外一个类中。
- 1
- 2
- 3
具体包括一下几种解决方案:
- 将网络请求抽象到单独的类中
- 将界面的拼装抽象到专门的类中
构造 ViewModel
这样抽象之后,View 只接受 ViewModel,而 Controller 只需要传递 ViewModel 这么一行代码。而另外构造 ViewModel 的过程,我们就可以移动到另外的类中了。专门构造存储类
二:MVP
MVP 模式将 Controller 改名为 Presenter,同时改变了通信方向。
1. 各部分之间的通信,都是双向的。
2. View 与 Model 不发生联系,都通过 Presenter 传递。
3. View 非常薄,不部署任何业务逻辑,称为”被动视图”(Passive View),即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。
三:MVVM
MVVM 模式将 Presenter 改名为 ViewModel,基本上与 MVP 模式完全一致。
MVVM的历史
相对于 MVC 的历史来说,MVVM 是一个相当新的架构,MVVM 最早于 2005 年被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出,并且应用在微软的软件开发中。当时 MVC 已经被提出了 20 多年了,可见两者出现的年代差别有多大。
MVVM的问题
MVVM 的作者 John Gossman 的 批评 应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点:
第一点:数据绑定使得 Bug 很难被调试。你看到界面异常了,有可能是你 View 的代码有 Bug,也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置,要定位原始出问题的地方就变得不那么容易了。
第二点:对于过大的项目,数据绑定需要花费更多的内存。
本篇文章是在读唐巧和阮一峰的博客后总结成的,许多地方直接复制粘贴了(链接如下)
http://blog.devtang.com/2015/11/02/mvc-and-mvvm/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
mvc结构:
视图(View):用户界面。
控制器(Controller):业务逻辑
模型(Model):数据保存
mvc各部分的通信方式
mvc互动模式
通过 View 接受指令,传递给 Controller。
另一种是直接通过controller接受指令。
mvc的历史
MVC 的概念最早出现在二十世纪八十年代的 施乐帕克 实验室中(对,就是那个发明图形用户界面和鼠标的实验室),当时施乐帕克为 Smalltalk 发明了这种软件设计模式。
- 1
controller层的臃肿问题
于 View 来说,你如果抽象得好,那么一个 App 的动画效果可以很方便地移植到别的 App 上。
对于 Model 来说,它其实是用来存储业务的数据的,如果做得好,它也可以方便地复用。
如果我们能够意识到 Controller 里面的代码不便于复用,我们就能知道什么代码应该写在 Controller 里面了,那就是那些不能复用的代码。
一个解决的思路
Controller 里面就只应该存放这些不能复用的代码,这些代码
在初始化时,构造相应的 View 和 Model。
监听 Model 层的事件,将 Model 层的数据传递到 View 层。
监听 View 层的事件,并且将 View 层的事件转发到 Model 层。
- 1
- 2
- 3
Controller 只有以上的这些代码,那么它的逻辑将非常简单,而且也会非常短。
controller进一步的解决方案
但是,我们却很难做到这一点,因为还是有很多逻辑我们不知道写在哪里,于是就都写到了 Controller 中了,那我们接下来就看看其它逻辑应该写在哪里。
将 UITableView 的 Data Source 分离到另外一个类中。
将数据获取和转换的逻辑分别到另外一个类中。
将拼装控件的逻辑,分离到另外一个类中。
- 1
- 2
- 3
具体包括一下几种解决方案:
- 将网络请求抽象到单独的类中
- 将界面的拼装抽象到专门的类中
构造 ViewModel
这样抽象之后,View 只接受 ViewModel,而 Controller 只需要传递 ViewModel 这么一行代码。而另外构造 ViewModel 的过程,我们就可以移动到另外的类中了。专门构造存储类
二:MVP
MVP 模式将 Controller 改名为 Presenter,同时改变了通信方向。
1. 各部分之间的通信,都是双向的。
2. View 与 Model 不发生联系,都通过 Presenter 传递。
3. View 非常薄,不部署任何业务逻辑,称为”被动视图”(Passive View),即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。
三:MVVM
MVVM 模式将 Presenter 改名为 ViewModel,基本上与 MVP 模式完全一致。
MVVM的历史
相对于 MVC 的历史来说,MVVM 是一个相当新的架构,MVVM 最早于 2005 年被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出,并且应用在微软的软件开发中。当时 MVC 已经被提出了 20 多年了,可见两者出现的年代差别有多大。
MVVM的问题
MVVM 的作者 John Gossman 的 批评 应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点:
第一点:数据绑定使得 Bug 很难被调试。你看到界面异常了,有可能是你 View 的代码有 Bug,也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置,要定位原始出问题的地方就变得不那么容易了。
第二点:对于过大的项目,数据绑定需要花费更多的内存。
本篇文章是在读唐巧和阮一峰的博客后总结成的,许多地方直接复制粘贴了(链接如下)
http://blog.devtang.com/2015/11/02/mvc-and-mvvm/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io