MVC,MVVM,MVP 优缺点

MVC

mvc

MVC的优缺点

优点

MVC的低耦合性、高重用性、可维护性等优点显而易见,使得原本复杂的代码与界面的交互变得简单、清晰、明了,开发者可以把更多的精力放在前端界面的设计上,而不用绞尽脑汁去思考究竟应该如何使界面得到同步,这样减轻了设计压力,也从另一方面使用户得到更多更好的享受体验

缺点

1.愈发笨重的Controller

2.太过于轻量级的Model

3.较差的可测试性

  • (MVC的另一个大问题是,它不鼓励开发人员编写单元测试。由于控制器混合了视图处理逻辑和业 务逻辑,分离这些成分的单元测试成了一个艰巨的任务。大多数人选择忽略这个任务,那就是不做 任何测试。
    上文提到了控制器可以管理视图的层次结构;控制器有一个“view”属性,并且可以通过IBOutlet访 问视图的任何子视图。当有很多outlet时这样做不易于扩展,在某种意义上,最好不要使用子视图 控制器(child view controller)来帮助管理子视图。
    在这里有多个模糊的标准,似乎没有人能完全达成一致。貌似无论如何,view和对应的controller 都紧紧的耦合在一起,总之,还是会把它们当成一个组件来对待。Apple提供的这个组件一度以来 在某种程度误导了大多初学者,初学者将所有的视图全部拖到xib中,连接大量的IBoutLet输出口属 性,都是一些列问题。
    )

4.遗失的网络逻辑

  • (苹果使用的MVC的定义是这么说的:所有的对象都可以被归类为一个Model,一个view,或是一个 控制器。就这些。那么把网络代码放哪里?和一个API通信的代码应该放在哪儿? 你可能试着把它放在Model对象里,但是也会很棘手,因为网络调用应该使用异步,这样如果一个网 络请求比持有它的Model生命周期更长,事情将变的复杂。显然也不应该把网络代码放在view里, 因此只剩下控制器了。这同样是个坏主意,因为这加剧了厚重控制器的问题。)

###5.定义模糊的“Manage”

##### ______之前我提到了view controller可以管理试图的层次结构;view controller有一个“view”属性,并且可以通过IBOutlet访问视图的任何子视图。当有很多outlet时这样做不易于扩展,在某种意义上,最好不要使用子视图控制器(child view controller)来帮助管理子视图(subview)。要点在哪?验证用户输入的业务逻辑应归入controller还是model呢?在这里有多个模糊的标准,似乎没有人能完全达成一致。貌似无论如何,view和对应的controller都紧紧的耦合在一起,总之,还是会把它们当成一个组件来对待。

MVVM

在经历了一大堆吐槽之后,诞生了MVVM(一个高大尚牛逼哄哄的名词,从此又多了一种人,你懂MVVM ?如果你的回答是否,瞬间被鄙视一把)。

mvvm

Model-View-ViewModel
  • 1.在MVVM里,view和view controller正式联系在一起,我们把它们视为一个组件。视图view仍然不能直接引用模型model,当然controller也不能。相反,他们引用视图模型view model。

  • 2.view model是一个放置用户输入验证逻辑,视图显示逻辑,发起网络请求和其他各种各样的代码的极好的地方。有一件事情不应归入view model,那就是任何视图本身的引用。view model的概念同时适用于于iOS和OS X。(换句话说,不要在view model中使用 #import UIKit.h)

    优点
  • 1.由于展示逻辑(presentation logic)放在了view model中,视图控制器本身就会不再臃肿。当你开始使用MVVM的最好方式是,可以先将一小部分逻辑放入视图模型,然后当你逐渐习惯于使用这个范式的时候再迁移更多的逻辑到视图模型中。
  • 2.使用MVVM的iOS app是高度可测试的;因为view model包含了所有的展示逻辑并且不会引用view,所以它可以通过编程方式充分测试
  • 3.使用MVVM会轻微的增加代码量,但总体上减少了代码的复杂性。这是一个划算的交易。


为什么要mvp
  • MVC、MVVM,真实的业务场景中,如果场景的逻辑异常复杂,在反复的迭代中仍会出现 各式各样的问题。真对MVVM我个人理解主要是将原来Controller中处理数据逻辑的代码统一归 到一个新的class(viewModel)中去,更甚之网络请求等工作全部从Controller移到viewModel。 刚一开始总觉的怪怪的。
  • MVVM层将对应的 一部分逻辑处理移植到了ViewModel中,这并没有从根本上解决问题,无非是将代码做了一份对应 的copy转移,并没有从根本上达到逻辑分层的概念。相反MVP模 式恰好解决了这一难题,MVP模式衍生于传统service架构,针对不同的业务场景图供对应的匹配的 抽象service服务,客户端拿到网络数据后未达到指定的目的,为满足相同抽象逻辑的业务场景,在客户端网络层与Model层之间加一协议层,Model层实现整个 协议层,之后在基于MVC的结构下将一概相同层次的,业务场景绘制解释到对应的View上。

MVP

传统web架构

932005-20160519205629529-1414980315.png

######(DTO是一个普通的Java类,它封装了要传送的批量的数据。当客户端需要读取服务器端的数 据的时候,服务器端将数据封装在DTO中,这样客户端就可以在一个网络调用中获得它需要的所有数据。)

现有模式:

932005-20160519205642654-263111041.png


mvp模式

932005-20160519205650466-1684490228.png

  • M : 逻辑Model层
  • V : 视图层
  • P : protocol协议层

  • Model层类似于MVVM的ViewModel,主要负责存储抽象逻辑数据,另外Model层主还有部分工作 实现对应的协议层协议,提供协议对应的各种属性以及服务。Model经过协议层抽象约束,最后 Model被抽象成具有统一抽象逻辑的业务场景,最终Model层在讲数据交付整个MVC结构绘制展 示的时间,我们可以按照同一套抽象的逻辑标准去执行。

___MVP模式的原则是:在service层提供一大堆不尽相同的业务场景之后,我们将这一系列数据全 部抽象归纳,通过定制一套标准的protocol协议,让不同业务场景的都去实现这一协议,最终将 数据全部装配、拼装成一套具有相同调度规则的统一编制话数据Model,之后我们采用 id的标准去操作数据。
___MVP除了将数据逻辑完全镇封的各自的Model,同时将哪些Model需要绘制,哪些Model需要校 验, 哪些Model需要接受处理点击Action这些逻辑全部由Model自己来决定,Controller只作为 一个粘合性的模版,Controller只处理一批具有共性的范型类数据,至于具体的操作操作毫不关 心。
*___MVP面相的更多的是在MVC上层与service之间追加了一层协议层,我们认为通过协议层处理过的数据是暂时可以客户端场景使用的数据,在数据到达MVC我们针对数据进行再加工、再构造处理,这一切全部在容器内操作。这一点完全与别的设计模式相反。
*___MVP并不是让用户在Model打上网络请求操作、在Model层执行[self.navigationController pushViewController:*]等这些操作,其实相对大多人来说对于部分对象生命周期长短问题还是 很在乎,所以在处理TemplateActionProtocol协议的时间,MVP只是对准Action做了一层抽象 封装。通过实现TemplateActionProtocol的Model会产生一个Action对象,最终通过block的调 用链传回控制器中,我们在控制器中统一做handler处理。
*___MVP我们最初设计目的就是为了强调一个装配概念,如果发生了业务场景的追加,控制器我不会 改动其中的代码,只需要将新数据追加成相同批次的ViewModel,然后配置进容器,之后控制器 不做任何修改就可以满足需求了。通过具体的剥离、抽取我们成功了的最大限度的剥离了控制 器,满足了轻量级Controller这一概念。
*___MVP与传统软件相比,在设计这一点的时间我们完全借鉴了传统软件的思维模式,Java平台的 service设计模式、三层架构这些设计规范都相对做了一些对比分析,最终得出了MVP这一理 念。

参考网址(http://www.jianshu.com/p/f7ff18ac1c31)

转载于:https://www.cnblogs.com/yangyongnian/p/5510521.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值