隨著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 實現。

設計 MVC 的重要目的就是在人的心智模型與計算機的模型之間建立一個橋樑，而 MVC 能夠解決這一問題並為使用者提供直接看到資訊和操作資訊的功能。

通過把資料模式從各種可以被存取和控制的資料中分離出來可以改善分散式系統的設計。MVC設計模式由三部分組成。模型是應用物件，沒有使用者介面。視圖表示它在螢幕上的顯示，代表流向使用者的資料。控制器定義使用者介面對使用者輸入的響應方式，負責把使用者的動作轉成針對Model的操作。Model 通過更新View的資料來反映資料的變化。

三者關係如圖： 

 MVC的分工與協作

3.MVC中的設計模式：

一個以MVC為架構的系統包含了很多的設計模式，但是與MVC最為密切相關的是下面三種模式：Observer, Composite和Strategy。

（1） Observer模式

Observer模式的結構圖：

（2） Composite模式

 Composite模式的結構圖：

（3） Strategy模式

 Strategy模式的結構圖：

二、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。

在 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 功能圖

View和邏輯分離出來,但這種資料繫結技術非常簡單實用，也是WPF所特有的，所以我們又稱之為Model-View-ViewModel(MVVM)。這種模式跟經典的MVP（Model-View-Presenter）模式很相似，除了你需要一個為View量身定製的model，這個model就是ViewModel。ViewModel包含所有由UI特定的介面和屬性，並由一個 ViewModel 的檢視的繫結屬性，並可獲得二者之間的鬆散耦合，所以需要在ViewModel 直接更新檢視中編寫相應程式碼。資料繫結系統還支援提供了標準化的方式傳輸到檢視的驗證錯誤的輸入的驗證。

作為一個開發者，有一個學習的氛圍跟一個交流圈子特別重要這是一個我的iOS交流群：687528266，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！