原文

　　簡書原文：https://www.jianshu.com/p/39f8f0aefdc2

大綱

　　1、認識MV*框架

　　2、傳統UI設計模式
　　3、對框架的本質認識——框架有效性和框架分類
　　4、MV*基礎概念
　　5、為什麽要用MV*框架

1、認識MV*框架

MV*術語表示基於瀏覽器的一系列框架，用於構建應用程序的關註分離。這些框架立足於傳統
的UI設計模式，但在整個實現過程中，其遵循某種模式的程度是變化的。

    在MV*概念中，M代表模型（Model）,V代表視圖（View）
    
    模型：典型的模型包含了數據、業務邏輯以及驗證邏輯。從概念上講，其代表諸如某個客
戶或某條支付之類的東西。模型從不關心數據的展示
    
    視圖：視圖即用戶所見以及交互的界面，是模型數據的可視化呈現。有賴於框架其他部分
（這些部分負責用戶交互的更新和相應），其可以是一個簡單結構：或者同樣有賴於MV*實現，
其也包含邏輯。
    
    第三部分：傳統UI設計模式包含了第三個組成部分，該部分幫助管理模型與視圖間的關系，
以及模型、視圖與用戶間的關系。盡管大多數MVC/MVVM結構的現代Web UI設計框架都包含了
模型與視圖的一些概念，但第三個組成部分在名稱及履行職責上卻不盡相同。因此，人們通常用
通配符*來泛指這個組成部分

2、傳統UI設計模式

2.1、MVC模式

　　MVC模式包含模型、視圖和控制器
　　控制器：控制器是應用程序的入口點，接受來自UI控件的信號。它還包含了處理用戶輸入的邏輯，以及基於接受到的輸入，發送命令給模型以更新模型狀態的處理邏輯。
　　與控制器的交互引發一個事件鏈，最終產生視圖更新。在此模式中，視圖能夠捕獲模型變化，並在觀察到模型改變時 進行視圖更新。

2.2、MVP模式

　　MVC的變體結構，模型-視圖-表示器，簡稱MVP。
　　該模式的出發點是進一步解耦模型與MVC其他兩個組件的關系。在MVP裏，類似控制器的對象與視圖一起表示用戶界面或呈現（Presentation）,模型則繼續表示數據管理。MVP裏沒有充當守護者角色的控制器。每個視圖都由一個被稱為表示器的組件來支持
　　表示器：表示器包含視圖的展示邏輯。視圖通過將職責委托給表示器，其僅僅用於相應用戶交互。表示器直接反問模型以獲取任何更新，並將數據更新傳給視圖。在這種方式下，表示器在模型和視圖之間扮演了中間人的角色。
　　表示器負責保持視圖與模型的更新。在視圖與模型中間建立一個對象，有利於視圖和模型聚焦於各自的職責。

2.3、MVVM模式

　　如同MVP一樣，MVVM的視圖也是入口點，而且MVVM的模型也有一個對象位於模型與視圖之間。在此模式中，第三個組成部分被稱為視圖模型：
　　視圖模型：視圖模型是視圖的模型或展示代碼，此外，其還是模型與視圖之間的中間人。所有定義及管理視圖的代碼都包含在視圖模型中。其包含了數據Property及展示邏輯。在模型中，每個需要在視圖裏得到反映的數據點，都映射到視圖模型的對應Property上。就像MVP的表示器，每個視圖都由一個視圖模型所支持。視圖模型能夠掌握視圖與模型的變化，並保持兩者同步。

3、對框架的本質認識——框架有效性和框架分類

    框架有效性優於框架分類
    視圖用傳統設計模式來一一匹配現今的MV*是徒勞的
    我希望看到開發者構建經過良好設計並遵循關註分離的強大應用，而非看到他們浪費時間
爭論什麽MV*的廢話。
    大多數MV*框架實現知識松散地以原始傳統設計模式為基礎進行設計，了解這一點，就能認
識到框架屬於哪種模式並不重要

4、MV*基礎概念

    模型：模型代表應用數據。其包含了訪問及管理數據所需的Property，處理邏輯與驗證。
模型常常還包含了業務邏輯。
    視圖：視圖是用戶所見並與之交互的部分，模型在這裏得以可視化呈現。在某些MV*實現中
，視圖還可能包含展示邏輯。
    模板：模板是視圖的可復用構件塊，用來處理視圖中的動態內容。其包含數據的占位符以
及其他模板內容渲染的指令。在SPA應用中通常會用到一個或多個模板來創建視圖。
    綁定：該屬於描述模型數據模板元素的關聯處理。某些MV*實現中還提供了其他類型綁定，
如事件與CSS樣式間的綁定。
    下圖(2.6)便展示了一個全局視圖，用來描述上述概念在SPA應用中的相互關系。這些概念
可能是SPA應用構建過程所需的最基本要求了。其他的一些特性，註入路由，也很常見(甚至必
須)，但未必得以普遍提供。

4.1、模型

    模型常常包含了業務邏輯與驗證，其也代表了應用數據。然而，模型所包含數據不應該
是無關信息的大雜燴。之所以稱之為模型，是因為它是一個對應用邏輯而言很重要的、顯示存在
的實體。
    每個模型都代表現實中的某個對象。
    系統越大越復雜，模型類型也就越多。
    模型對照現實世界的失誤，其包含的不僅是數據，還有行為。

4.2、綁定

    綁定(Binding)：直接的意思是把兩個東西綁/連接在一起。該術語指的是將視圖的UI元素
與代碼相關部分聯系起來（比如某個模型的數據）
    綁定內容並非僅限於數據。不同的庫和框架支持不同的綁定類型。樣式、屬性以及click
這樣的事件都可以綁定到UI。依賴於所選框架，綁定類型也不盡相同。

4.3、模板(Template)

    模板是HTML片段，其作為視圖如何渲染的方式。渲染方式可以額外包含多種綁定及其他指
令，決定模板及其模型數據如何處理。顧名思義，模板是可重用的。
    一個視圖由一個或多個模板創建，而復雜視圖通常有多個渲染模板同時呈現。無論是內建
或借助外部庫，MV*框架中將模板和模型數據結合起來的那部分，通常被稱為模板引擎
（Template Engine）

4.4、視圖

    如討論模板時所述，想Knockout或AngularJs這類的框架在模板中使用聲明式綁定，通常
采用在HTML元素上添加特定屬性的方式。在這些框架裏，模板和視圖差不多是同一類東西。因
此，當使用這些框架構建視圖時，需要考慮采取內嵌模板還是按需下載的方式。這更像一個設
計問題。

5、為什麽要用MV*框架

5.1、傳統設計模式與MV*框架

    傳統設計模式包括MVC、MVP、MVVM等設計模式
    MV*框架指的是概念中融入了MVC、MVP、MVVM等設計模式的框架，但是由於某個框架有
時候並不能以某種設計模式完全概括，換句話說，一個框架中可能糅合了一個、兩個甚至三個的
設計模式的思想。需要註意的，對於框架本身所展示的設計模式哪種並不是最重要的，重要的
是框架本身基於的是MV*這些傳統設計模式的思想而實現某些對底層功能的封裝。

5.2、關註分離

    MV*框架提供一種手段，基於底層設計模式，將JavaScript對象劃分為不同角色，代碼的
每部分都可以各司其職。
    
    代碼的每部分都可以專註於各自職責——這個關註分離的首要概念有利於設計針對特定目的
的對象。模型可以專註於數據；視圖可以專註於數據展現；而諸如控制器、表示器以及視圖模型
等組成部分則可以解耦模型與視圖，並維持兩者間的通信。越是將對象聚焦於單一目的，編碼、
測試及上線後的更改也就變得越容易。
    
    MV*框架通過特定機制，要求我們遵循特定方式編寫代碼以達到松耦合目的，這樣就降低了
意大利面條式代碼（指的是html\js\jsp等代碼相互交纏，各種綁定各種緊密耦合的代碼）產生
的可能性。

    其次，通過移除內嵌的JavaScript和CSS代碼，能夠盡可能保持HTML代碼的幹凈。同時避
免JavaScript與DOM元素間的緊耦合。

5.3、可擴展性

    MV*框架內在強化了關註分離的概念。反過來，這也使得項目更具有可擴展性，因為松耦合
的對象往往稍加調整就能夠在其他對象中重用。
    在MV*中，對象還可以完全交換處理以替換成新功能，同時不會再項目中產生巨大的連鎖反
應。這使得項目成長方式更優雅，因為代碼改變的負面影響要小得多。

《SPA設計與架構》之MV*框架