内容字号:默认大号超大号

段落设置:段首缩进取消段首缩进

字体设置:切换到微软雅黑切换到宋体

iOS架构模式MVC+MVP+mvvm架构

2018-06-26 17:51 出处:清屏网 人气: 评论(0

随着iOS职位的火热,越来越多的人都想成为一名优秀的iOS开发工程师,那么在竞争激烈的时代,应该如何成为一名iOS开发工程师呢?现在让大家了解一下iOS架构模式

作为一个开发者,有一个学习的氛围跟一个交流圈子特别重要这是一个我的iOS交流群:687528266,不管你是小白还是大牛欢迎入驻 ,分享BAT,阿里面试题、面试经验,讨论技术, 大家一起交流学习成长!

首先来说我们MVC+MVP+mvvm架构模式吧

一、MVC架构模式

1.MVC介绍:

MVC(Model-View-Controller)应用程序结构被用来分析分布式应用程序的特征。这种抽象结构能有助于将应用程序分割成若干逻辑部件,使程序设计变得更加容易。

在MVC结构中,模型(Model)代表应用程序的数据(data)和用于控制访问和修改这些数据的业务规则(business rule)。通常模型被用来作为对现实世界中一个处理过程的软件近似,当定义一个模型时,可以采用一般的简单的建模技术。

当模型发生改变时,它会通知视(View),并且为视提供查询模型相关状态的能力。同时,它也为控制器(Controller)提供访问封装在模型内部的应用程序功能的能力。

2.设计 MVC 的重要目的:

就是在人的心智模型与计算机的模型之间建立一个桥梁,早期的 MVC作为架构模式中最出名并且应用最广泛的架构模式,MVC 并没有一个明确的定义,网上流传的 MVC 架构图也是形态各异,作者查阅了很多资料也没有办法确定到底什么样的架构图才是标准的MVC 实现。

image

设计 MVC 的重要目的就是在人的心智模型与计算机的模型之间建立一个桥梁,而 MVC 能够解决这一问题并为用户提供直接看到信息和操作信息的功能。

通过把数据模式从各种可以被存取和控制的数据中分离出来可以改善分布式系统的设计。MVC设计模式由三部分组成。模型是应用对象,没有用户界面。视图表示它在屏幕上的显示,代表流向用户的数据。控制器定义用户界面对用户输入的响应方式,负责把用户的动作转成针对Model的操作。Model 通过更新View的数据来反映数据的变化。

三者关系如图:

image

MVC的分工与协作

image

image

3.MVC中的设计模式:

一个以MVC为架构的系统包含了很多的设计模式,但是与MVC最为密切相关的是下面三种模式:Observer, Composite和Strategy。

(1) Observer模式

Observer模式的结构图:

image

(2) Composite模式

Composite模式的结构图:

image

(3) Strategy模式

Strategy模式的结构图:

image

二、MVP架构模式

1.MVP 介绍

全称:Model-View-Presenter ;MVP 是从经典的模式MVC演变而来,它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。

2.MVP与MVC有着一个重大的区别

在MVP中View并不直接使用Model,它们之间的通信是通过Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是通过 Controller。

在MVC里,View是可以直接访问Model的!从而,View里会包含Model信息,不可避免的还要包括一些业务逻辑。 在MVC模型里,更关注的Model的不变,而同时有多个对Model的不同显示,即View。所以,在MVC模型里,Model不依赖于View,但是View是依赖于Model的。不仅如此,因为有一些业务逻辑在View里实现了,导致要更改View也是比较困难的,至少那些业务逻辑是无法重用的。

3.MVP - 保证了职责划分的(promises delivered) Cocoa MVC

看起来确实很像 Apple 的 MVC 对吧?确实蛮像,它的名字是 MVP(被动变化的 View)。回想一下,在 MVC 里面 View 和 Controller 是耦合紧密的,但是对于 MVP 里面的 Presenter 来讲,它完全不关注 ViewController 的生命周期,而且 View 也能被简单 mock 出来,所以在 Presenter 里面基本没什么布局相关的代码,它的职责只是通过数据和状态更新 View。

image

在 MVP 架构里面,UIViewController 的那些子类其实是属于 View 的,而不是 Presenter。这种区别提供了极好的可测性,但是这是用开发速度的代价换来的,因为你必须要手动的去创建数据和绑定事件,像下面这段代码中做的一样:

import UIKit

struct Person { // Model    let firstName: String    let lastName: String}

protocol GreetingView: class {    func setGreeting(greeting: String)}

protocol GreetingViewPresenter {    init(view: GreetingView, person: Person)    func showGreeting()}

class GreetingPresenter : GreetingViewPresenter {    unowned let view: GreetingView    let person: Person    required init(view: GreetingView, person: Person) {        self.view = view        self.person = person    }    func showGreeting() {        let greeting = "Hello" + " " + self.person.firstName + " " + self.person.lastName        self.view.setGreeting(greeting)    }}

class GreetingViewController : UIViewController, GreetingView {    var presenter: GreetingViewPresenter!    let showGreetingButton = UIButton()    let greetingLabel = UILabel()    override func viewDidLoad() {        super.viewDidLoad()        self.showGreetingButton.addTarget(self, action: "didTapButton:", forControlEvents: .TouchUpInside)    }    func didTapButton(button: UIButton) {        self.presenter.showGreeting()    }    func setGreeting(greeting: String) {        self.greetingLabel.text = greeting    }    // layout code goes here}

// Assembling of MVP

let model = Person(firstName: "David", lastName: "Blaine")

let view = GreetingViewController()

let presenter = GreetingPresenter(view: view, person: model)

view.presenter = presenter

在MVP里,Presenter完全把Model和View进行了分离,主要的程序逻辑在Presenter里实现。而且,Presenter与具体的View是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更View时候可以保持Presenter的不变,即重用! 不仅如此,我们还可以编写测试用的View,模拟用户的各种操作,从而实现对Presenter的测试--而不需要使用自动化的测试工具。 我们甚至可以在Model和View都没有完成时候,就可以通过编写Mock Object(即实现了Model和View的接口,但没有具体的内容的)来测试Presenter的逻辑。 在MVP里,应用程序的逻辑主要在Presenter里实现,其中的View是很薄的一层。因此就有人提出了Presenter First的设计模式,就是根据User Story来首先设计和开发Presenter。在这个过程中,View是很简单的,能够把信息显示清楚就可以了。在后面,根据需要再随便更改View,而对Presenter没有任何的影响了。 如果要实现的UI比较复杂,而且相关的显示逻辑还跟Model有关系,就可以在View和Presenter之间放置一个Adapter。由这个 Adapter来访问Model和View,避免两者之间的关联。而同时,因为Adapter实现了View的接口,从而可以保证与Presenter之间接口的不变。这样就可以保证View和Presenter之间接口的简洁,又不失去UI的灵活性。 在MVP模式里,View只应该有简单的Set/Get的方法,用户输入和设置界面显示的内容,除此就不应该有更多的内容,绝不容许直接访问Model--这就是与MVC很大的不同之处。

三、mvvm架构模式

1.MVVM介绍

是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化,让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了,它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。微软的WPF带来了新的技术体验,如Silverlight、音频、 视频3D 、动画……,这导致了软件UI层更加细节化、可定制化。同时,在技术层面,WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去,以应对客户日益复杂的需求变化。

WPF的数据绑定与Presentation Model相结合是非常好的做法,使得开发人员可以将

2.MVVM 功能图

image

image

image

View和逻辑分离出来,但这种数据绑定技术非常简单实用,也是WPF所特有的,所以我们又称之为Model-View-ViewModel(MVVM)。这种模式跟经典的MVP(Model-View-Presenter)模式很相似,除了你需要一个为View量身定制的model,这个model就是ViewModel。ViewModel包含所有由UI特定的接口和属性,并由一个 ViewModel 的视图的绑定属性,并可获得二者之间的松散耦合,所以需要在ViewModel 直接更新视图中编写相应代码。数据绑定系统还支持提供了标准化的方式传输到视图的验证错误的输入的验证。

分享给小伙伴们:
本文标签: MVCMVPmvvmiOS架构

相关文章

发表评论愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。

CopyRight © 2015-2016 QingPingShan.com , All Rights Reserved.

清屏网 版权所有 豫ICP备15026204号