前端面試查漏補缺--(十一) 前端軟件架構模式MVC/MVP/MVVM

前言

本系列最開始是爲了本身面試準備的.後來發現整理愈來愈多,差很少有十二萬字符,最後決定仍是分享出來給你們.

爲了分享整理出來,花費了本身大量的時間,起碼是隻本身用的三倍時間.若是喜歡的話,歡迎收藏,關注我!謝謝!

文章連接

• 前端面試查漏補缺--(一) 防抖和節流
• 前端面試查漏補缺--(二) 垃圾回收機制
• 前端面試查漏補缺--(三) 跨域及常看法決辦法
• 前端面試查漏補缺--(四) 前端本地存儲
• 前端面試查漏補缺--(五) 渲染機制及重繪和迴流
• 前端面試查漏補缺--(六) 瀏覽器緩存
• 前端面試查漏補缺--(七) XSS攻擊與CSRF攻擊
• 前端面試查漏補缺--(八) 前端加密
• 前端面試查漏補缺--(九) HTTP與HTTPS
• 前端面試查漏補缺--(十) 前端鑑權
• 前端面試查漏補缺--(十一) 前端軟件架構模式MVC/MVP/MVVM
• 前端面試查漏補缺--(十二) 從輸入URL到看到頁面發生的全過程(含三握手,四揮手詳解)
• 前端面試查漏補缺--(十三) 內存泄漏
• 前端面試查漏補缺--(十四) 算法及排序
• 前端面試查漏補缺--(十五) Event Loop

合集篇:

前端面試查漏補缺--Index篇(12萬字符合集) 包含目前已寫好的系列其餘十幾篇文章.後續新增值文章不會再在每篇添加連接,強烈建議議點贊,關注合集篇!!!!,謝謝!~

後續更新計劃

後續還會繼續添加設計模式,前端工程化,項目流程,部署,閉環,vue常考知識點 等內容.若是以爲內容不錯的話歡迎收藏,關注我!謝謝!

求一分內推

目前本人也在準備跳槽,但願各位大佬和HR小姐姐能夠內推一份靠譜的武漢 前端崗位!郵箱:bupabuku@foxmail.com.謝謝啦!~

概述

MVC，MVP和MVVM都是常見的軟件架構設計模式（Architectural Pattern），它經過分離關注點來改進代碼的組織方式。不一樣於設計模式（Design Pattern），只是爲了解決一類問題而總結出的抽象方法，一種架構模式每每使用了多種設計模式。

要了解MVC、MVP和MVVM，就要知道它們的相同點和不一樣點。不一樣部分是C(Controller)、P(Presenter)、VM(View-Model)，而相同的部分則是MV(Model-View)。

MVC模式

MVC模式（Model–view–controller）:
是軟件工程中的一種軟件架構模式，把軟件系統分爲三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。

• 模型（Model） - Model層用於封裝和應用程序的業務邏輯相關的數據以及對數據的處理方法。一旦數據發生變化，模型將通知有關的視圖。
• 視圖（View） - View做爲視圖層，主要負責數據的展現,而且響應用戶操做.
• 控制器（Controller）- 控制器是模型和視圖之間的紐帶，接收View傳來的用戶事件而且傳遞給Model，同時利用從Model傳來的最新模型控制更新View.

數據關係:

• View 接受用戶交互請求
• View 將請求轉交給Controller
• Controller 操做Model進行數據更新
• 數據更新以後，Model通知View更新數據變化.PS: 還有一種是View做爲Observer監聽Model中的任意更新，一旦有更新事件發出，View會自動觸發更新以展現最新的Model狀態.這種方式提高了總體效率，簡化了Controller的功能，不過也致使了View與Model之間的緊耦合。
• View 更新變化數據

方式:

全部方式都是單向通訊

結構實現:

• View ：使用 組合(Composite)模式
• View和Controller：使用 策略(Strategy)模式
• Model和 View：使用 觀察者(Observer)模式同步信息

缺點:

• View層太重: View強依賴於Model的,而且能夠直接訪問Model.因此不可避免的View還要包括一些業務邏輯.致使view太重,後期修改比較困難,且複用程度低.
• View層與Controller層也是耦合緊密: View與Controller雖然看似是相互分離，但倒是聯繫緊密.常常View和Controller一一對應的，捆綁起來做爲一個組件使用.解耦程度不足.

MVP模式

MVP（Model-View-Presenter）是MVC模式的改良.MVP與MVC有着一個重大的區別：在MVP中View並不直接使用Model，它們之間的通訊是經過Presenter (MVC中的Controller)來進行的，全部的交互都發生在Presenter內部，而在MVC中View會直接從Model中讀取數據而不是經過 Controller。

• Model - Model層依然是主要與業務相關的數據和對應處理數據的方法。
• View - View依然負責顯示,但MVP中的View並不能直接使用Model
• Presenter - Presenter做爲View和Model之間的「中間人」，且MVP中的View並不能直接使用Model，而是經過爲Presenter提供接口，讓Presenter去更新Model，再經過觀察者模式更新View。

數據關係:

• View 接收用戶交互請求
• View 將請求轉交給 Presenter
• Presenter 操做Model進行數據更新
• Model 通知Presenter數據發生變化
• Presenter 更新View數據

方式:

各部分之間都是雙向通訊

結構實現:

• View ：使用 組合(Composite)模式
• View和Presenter：使用 中介者(Mediator)模式
• Model和Presenter：使用 命令(Command)模式同步信息

MVC和MVP關係

• MVP：是MVC模式的變種。
• 項目開發中，UI是容易變化的，且是多樣的，同樣的數據會有N種顯示方式；業務邏輯也是比較容易變化的。爲了使得應用具備較大的彈性，咱們指望將UI、邏輯（UI的邏輯和業務邏輯）和數據隔離開來，而MVP是一個很好的選擇。
• Presenter代替了Controller，它比Controller擔當更多的任務，也更加複雜。Presenter處理事件，執行相應的邏輯，這些邏輯映射到Model操做Model。那些處理UI如何工做的代碼基本上都位於Presenter。
• MVC中的Model和View使用Observer模式進行溝通；MPV中的Presenter和View則使用Mediator模式進行通訊；Presenter操做Model則使用Command模式來進行。基本設計和MVC相同：Model存儲數據，View對Model的表現，Presenter協調二者之間的通訊。在MVP 中 View 接收到事件，而後會將它們傳遞到 Presenter, 如何具體處理這些事件，將由Presenter來完成。

MVP的優勢:

• Model與View徹底分離，修改互不影響
• 更高效地使用，由於全部的邏輯交互都發生在一個地方—Presenter內部
• 一個Preseter可用於多個View，而不須要改變Presenter的邏輯（由於View的變化老是比Model的變化頻繁）。
• 更便於測試。把邏輯放在Presenter中，就能夠脫離用戶接口來測試邏輯（單元測試）

MVP的缺點:

• Presenter中除了業務邏輯之外，還有大量的View->Model，Model->View的手動同步邏輯，形成Presenter比較笨重，一旦視圖須要變動，那麼Presenter也須要變動,維護起來比較困難。

MVVM模式

MVVM是Model-View-ViewModel的簡寫。由Microsoft提出，並經由Martin Fowler佈道傳播。在 MVVM 中，不須要Presenter手動地同步View和Model.View 是經過數據驅動的，Model一旦改變就會相應的刷新對應的 View，View 若是改變，也會改變對應的Model。這種方式就能夠在業務處理中只關心數據的流轉，而無需直接和頁面打交道。ViewModel 只關心數據和業務的處理，不關心 View 如何處理數據，在這種狀況下，View 和 Model 均可以獨立出來，任何一方改變了也不必定須要改變另外一方，而且能夠將一些可複用的邏輯放在一個 ViewModel 中，讓多個 View 複用這個 ViewModel。

• Model - Model層僅僅關注數據自己，不關心任何行爲（格式化數據由View負責），這裏能夠把它理解爲一個相似json的數據對象。
• View - MVVM中的View經過使用模板語法來聲明式的將數據渲染進DOM，當ViewModel對Model進行更新的時候，會經過數據綁定更新到View。
• ViewModel - 相似與Presenter. ViewModel會對View 層的聲明進行處理.當 ViewModel 中數據變化，View 層會進行更新;若是是雙向綁定,一旦View對綁定的數據進行操做，則ViewModel 中的數據也會進行自動更新.

數據關係:

• View 接收用戶交互請求
• View 將請求轉交給ViewModel
• ViewModel 操做Model數據更新
• Model 更新完數據，通知ViewModel數據發生變化
• ViewModel 更新View數據

方式:

雙向綁定。View/Model的變更，自動反映在 ViewModel，反之亦然。

實現數據綁定的方式：

• 數據劫持 (Vue)
• 發佈-訂閱模式 (Knockout、Backbone)
• 髒值檢查 (舊版Angular)

使用:

• 能夠兼容你當下使用的 MVC/MVP 框架。
• 增長你的應用的可測試性。
• 配合一個綁定機制效果最好。

MVVM優勢:

MVVM模式和MVC模式同樣，主要目的是分離視圖（View）和模型（Model），有幾大優勢:

• 1,低耦合。View能夠獨立於Model變化和修改，一個ViewModel能夠綁定到不一樣的」View」上，當View變化的時候Model能夠不變，當Model變化的時候View也能夠不變。
• 2,可重用性。你能夠把一些視圖邏輯放在一個ViewModel裏面，讓不少view重用這段視圖邏輯。
• 3, 獨立開發。開發人員能夠專一於業務邏輯和數據的開發（ViewModel），設計人員能夠專一於頁面設計，生成xml代碼。
• 4, 可測試。界面素來是比較難於測試的，而如今測試能夠針對ViewModel來寫。

MVVM缺點:

• 類會增多，ViewModel會越加龐大，調用的複雜度增長。

感謝及參考

• GUI 應用程序架構的十年變遷：MVC、MVP、MVVM、Unidirectional、Clean
• 【框架篇】mvc、mvp、mvvm使用關係總結
• MVC，MVP 和 MVVM的圖示
• 淺析前端開發中的 MVC/MVP/MVVM 模式