先後端分層架構MVC&MVVM

早期

---

 

特色

　　頁面由 JSP、PHP 等工程師在服務端生成

　　JSP 裏揉雜大量業務代碼

　　瀏覽器負責展示，服務端給什麼就展示什麼，展示的控制在 Web Server 層

優勢

　　簡單明快，本地起一個 Tomcat 或 Apache 就能開發，調試什麼的都還好，只要業務不太複雜。

缺點

　  前端難以搭建本地環境

　　代碼重用性，擴展性，維護性很低

後端 MVC 開發

---

 

特色

• View：進行數據顯示。
• Model：用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。
• Controller：處理用戶交互，負責轉發請求，並對請求進行處理（向模型請求數據或發送數據）

  服務器端的MVC流程：

  客戶端發送請求 -> 服務器觸發Controller -> 服務器進行Model各類操做 -> 服務器根據Model數據渲染View -> 服務器回覆請求，包含了整個View的html -> 客戶端從新渲染整個頁面，全部的css都又計算了一遍，全部的js都從新執行了一遍，全部的資源都從新請求了一遍（雖然可能已經cache了）

 

優勢

　　代碼可維護性獲得明顯好轉

　　線上模板的渲染仍是由java來作的，造成的是帶有動態數據的html，比較有利於SEO

缺點

　   隨着不一樣終端的出現，前端的工做量變大。可是前端依然依賴着後端（都在一個項目中進行開發）

　　先後端職責依舊糾纏不清

先後端分離

---

 

特色

　　ajax帶來了Web開發革命性的變化。前端和應用服務器分離，前端和後端經過Ajax來通訊。

　　先後端分工，前端使用ajax與後端數據交互，操做視圖，甚至控制部分路由，後端提供服務與數據。

 

優勢

 　 先後端的分工很是清晰

缺點

　  前端邏輯愈來愈重，愈來愈複雜，路由很差掌控。過度使用ajax不利於SEO。前端不坑重負

　  這與 JSP 時代區別不大。複雜度從服務端的 JSP 裏移到了瀏覽器的 JavaScript，瀏覽器端變得很複雜

前端分層

---

 

特色

　　後端思想在前端進行應用 

　　前端代碼變得也須要保存數據、處理數據、生成視圖（SPA），這致使了前端 MVC 框架的誕生

　　前端的MVC只是後端MVC中的View裏面再去分出來的MVC。前端的MVC是爲了解決複雜前端狀況下模塊化 JS的問題。

　　一個事件的發生是這樣的過程：
　　1. 用戶和應用產生交互。
　　2. 控制器的事件處理器被觸發。
　　3. 控制器從模型中請求數據，並將其交給視圖。
　　4. 視圖將數據呈現給用戶。

　　模型

　　用來存放應用的全部數據對象。好比，可能有一個User模型，用以存放用戶列表、他們的屬性及全部與模型有關的邏輯；當控制器從服務器抓取數據或建立新的記錄時，它就將數據包裝成模型實例。也就是說，咱們的數據是面向對象的，任何定義在這個數據模型上的函數或邏輯均可以直接被調用。

　　視圖

　　呈現給用戶的，用戶與之產生交互。在JavaScript應用中，視圖大都是由HTML、CSS、JavaScript模板組成的。除了模板中簡單的條件語句以外，視圖不該當包含任何其餘邏輯。
　　將邏輯混入視圖之中是編程的大忌，這並非說MVC不容許包含視覺呈現相關的邏輯，只要這部分邏輯沒有定義在視圖以內便可。咱們將視覺呈現邏輯歸類爲「視圖助手」（helper）：和視圖相關的獨立的小工具函數。

　　控制器

　　模型和視圖之間的紐帶。控制器從視圖獲取事件和輸入，對它們（極可能包含模型）進行處理，並相應地更新視圖。當頁面加載時，控制器會給視圖添加事件監聽，好比監聽表單提交或按鈕點擊。而後，當用戶和你的應用產生交互時，控制器中的事件觸發器就開始工做了。

 

後端MVC中的view是前端MCV的所有

 

　　前端MVC流程（前端其實大部分是MV+X，不必定有Controller):

　　客戶端根據用戶的行爲修改客戶端Model -> 客戶端更新和該Model相關的View -> 客戶端Model發送sync請求到服務器，只包含改變了哪些數據 -> 服務器審覈數據改動是否合法，只需回覆是否修改爲功 -> 客戶端收到成功，什麼都不用作；不成功，則把剛纔改的View改回來，而後通知用戶。（固然，也能夠在客戶端的Model裏面也加入審覈機制，這樣對不合法數據的反應更快，但仍是得保留服務器端的審覈）

　　比較一下能夠看到，前端MVC須要向服務器端傳遞和接收的數據量都少不少，而前端要作的等待和渲染工做也少了不少。換言之，會提供更快的交互反饋，也意味着更好的用戶體驗。同時，服務器端的負載也略有下降，由於基本上只須要在數據庫上提供一個RESTful API便可。

優勢

　　清晰的分工，可讓開發並行

　　部署相對獨立，產品體驗能夠快速改進。

缺點

　　開發者在代碼中大量調用相同的DOM API, 處理繁瑣，操做冗餘，使得代碼難以維護。

　　大量的DOM 操做使頁面渲染性能下降，加載速度變慢，影響用戶體驗。

　　當 Model 頻繁發生變化，開發者須要主動更新到View ；當用戶的操做致使Model發生變化，開發者一樣須要將變化的數據同步到Model中， 這樣的工做不只繁瑣，並且很難維護複雜多變的數據狀態。

MVVM 模式

---

 

特色

另外一些框架提出 MVVM 模式，用 View Model 代替 Controller。

• Model
• View
• View-Model：簡化的 Controller，爲 View 提供處理好的數據，不含其餘邏輯。

本質：view 綁定 view-model，視圖與數據模型強耦合。數據的變化實時反映在 view 上，不須要手動處理。

 

優勢　

　　前端應用的複雜程度已不一樣往日，暴露出了三個痛點問題：

　　開發者在代碼中大量調用相同的DOM API, 處理繁瑣，操做冗餘，使得代碼難以維護。

　　大量的DOM 操做使頁面渲染性能下降，加載速度變慢，影響用戶體驗。

　　當 Model 頻繁發生變化，開發者須要主動更新到View ；當用戶的操做致使Model發生變化，開發者一樣須要將變化的數據同步到Model中， 這樣的工做不只繁瑣，並且很難維護複雜多變的數據狀態。

　　早期 jQuery 的出現就是爲了前端能更簡潔的操做DOM 而設計的，但它只解決了第一個問題，另外兩個問題始終伴隨着前端一直存在。

　　MVVM 的出現，完美解決了以上三個問題。

　　MVVM 的三部分：

　　 Model 層表明數據模型，也能夠在Model中定義數據修改和操做的業務邏輯；

　　View 表明UI 組件，它負責將數據模型轉化成UI 展示出來，

　　ViewModel 是一個同步View 和 Model的對象。

　　View 和 Model 之間並無直接的聯繫，而是經過ViewModel進行交互。

　　ViewModel 經過雙向數據綁定把 View 層和 Model 層鏈接了起來，而View 和 Model 之間的同步工做徹底是自動的，無需人爲干涉，所以開發者只需關注業務邏輯，不須要手動操做DOM, 不須要關注數據狀態的同步問題，複雜的數據狀態維護徹底由 MVVM 來統一管理。

缺點

　 　 代碼不能複用。好比後端依舊須要對數據作各類校驗，校驗邏輯沒法複用瀏覽器端的代碼。若是能夠複用，那麼後端的數據校驗能夠相對簡單化。
　　 全異步，對 SEO 不利。每每還須要服務端作同步渲染的降級方案。
　　 性能並不是最佳，特別是移動互聯網環境下。

 

參考：https://blog.csdn.net/u010924834/article/details/51025127 

　　   https://github.com/lifesinger/blog/issues/184