全棧設計模式套餐MVVM, RESTful, MVC的歷史探索

衆所周知, 軟件開發時遵照一個規範的設計模式很是重要, 學習行業內主流的design pattern每每可以爲你節省大部分時間.html

根據我2年的全棧經驗, 在Web應用程序領域最流行的, 而且若干年內不會過期的設計模式套餐分別是: 前端的MVVM, 後端的MVC, 以及中間的restful api設計模式, 這三個設計模式的搭配很是完美, 以致於幾乎全部的互聯網服務都效仿這個標準來開發應用.前端

可是很遺憾, 不少新人仍是喜歡培養本身的編程風格, 甚至認爲本身的開放方式比主流的設計模式在某些方面更優秀, 若是有這個思想說明你的確是個聰明,積極的程序員, 但必定沒有太多經驗, 由於dalao們開發任何一款app都會遵循相關的設計模式, 寧願放棄也許存在的更好的'冷門模式',也要從衆, 這就說明主流模式的存在必定有他們存在的意義.vue

 

學習設計模式的好處

摘自書上:react

幫助咱們將應用組織成容易瞭解,容易維護,具備彈性的架構,創建可維護的系統,要訣在於隨時想到系統之後可能須要的變化以及應付變化的原則。程序員

一、設計模式能讓程序員之間更有默契

程序員A:我這個項目用了XXX設計模式web

程序員B:那我大體瞭解你程序的設計思路了, 我知道該怎麼閱讀你的代碼了!數據庫

二、易維護, 易擴展

PM:今天客戶有這樣一個新需求…你看能不能實現[懼怕]編程

程序員:明白了,還好我使用了XXX設計模式,因此改起來很快後端

三、設計模式讓你快速的開發一個項目, 減小思考的時間

程序員A:你怎麼想到要這樣去構建你的代碼?設計模式

程序員B:在我學習了XXX設計模式以後,對領導的需求馬上就能抽象成相關的架構, 很是舒服!!

 

因此說, 遵照設計模式是爲了應對新的變化和新的'人'

全棧設計模式的歷史

數據顯示分離時代

如今後端MVC太經典了, 但mvc是從前端的'數據顯示分離'進化而來的, 

原來舊PC時代, 大概上個世紀的'數據顯示分離'設計模式只是適用於單機的app, 不參與任何網絡服務, 好比小遊戲, 這時候將數據和顯示分紅2層很是完美, 可是後來隨着本地數據庫和其餘永久性存儲的解決方案出現之後, 2層分離明顯不夠用了, 因而就有了MVC的雛形...

前端mvc時代

這時候mvc還未發展成熟, 其中的中間層'controller'僅僅是起到一個過濾做用, 同時爲了知足多人合做開發應用的需求, 也使得這個'僞mvc'的3層結構變得異常多樣化, 這個特殊時代前端的設計模式是五花八門的, 很是混亂, 惋惜我也沒經歷過那個年代(大概在web1.0早期), 但能夠確定正是那時候最先的一批web開發者的努力探索, 纔有咱們今天優秀的設計模式可參考.

 

先後端分離時代

後來慢慢的單機app再也不流行, 取而代之的是網絡app, 也就是web應用, 這時候mvc的設計思想正式被規範化了, 這裏規定了, 中間層做爲主線控制邏輯, 數據層和顯示層做爲輔助模塊而存在, 這時候架構師思考應用的'主線劇情'始終綁定在中間的'邏輯控制層'

這個時代仍然是過渡時代, 由於分離, 造成了前端mvc+後端mvc的混沌局面, 這時候產生了一個核心問題: "業務的重心放在前端仍是後端?"

RESTful API的誕生 --- 後端已成熟

restful api的誕生具備劃時代的意義, 由於它定義了全部網際服務的接口規範(不是標準), 而且將全部服務器提供的服務都概括爲'增刪改查'.

REST全稱是Representational State Transfer,中文意思是表述性狀態轉移。 它首次出如今2000年Roy Fielding(HTTP規範的主要編寫者之一)的博士論文中。 他在論文中提到:"我這篇文章的寫做目的,就是想在符合架構原理的前提下,理解和評估以網絡爲基礎的應用軟件的架構設計,獲得一個功能強、性能好、適宜通訊的架構。" 若是一個架構符合REST的約束條件和原則,咱們就稱它爲RESTful架構。

RESTful設計模式真正成熟是在2009年左右, 移動互聯網全面來襲的時候, 徹底遵照了原web2.0時代還沒有飽和的REST(由於還有許多歷史遺留的過期模式), 幾乎全部手機app無一例外的使用了Http(s)來實現本身的業務, 甚至不少直接照搬了html那一套框架, 移動互聯網來的太猛烈, 沒有時間所有定製本身的技術和設計模式, 因此http+rest此時成爲壟斷性的行業規範.

REST是創建在HTTP之上的哲學, 固然也完美遵循了http的request和response一一對應的經典模式, 能夠說, REST是HTTP的深入總結, HTTP是REST的完美實現.

除此以外, restful和mvc也完美的結合, 成爲後端的開發標準, restful主要體如今後端mvc的邏輯控制層, 進行數據轉發接收以及用戶驗證, 當今不少web框架都支持restful+mvc,好比Express.js, .Net, Apache

推薦ruanyif的博客, 裏面詳細介紹了rest的思想:

http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html

MVVM的誕生 --- 前端已成熟

移動互聯網以後,後端已經穩定, 前端也在慢慢發生着變革, 前端由傳統的mvc漸漸演變成MVVM:

什麼是MVVM?MVVM是Model-View-ViewModel的縮寫。mvvm由微軟提出, 它的誕生是爲了解決前端的問題: 前面說先後端分離時代的新問題'業務重心放前端仍是後端'後來的趨勢是, 愈來愈多的計算任務放在了前端, 只將和安全有關的任務放在後端作, 這時候前端人員的工做量異常的巨大, 因而你們但願可以將'數據綁定''這樣的體力勞動讓系統本身負責, 因而就有了mvvm, mvvm的核心就是數據綁定, 換句話說是讓數據與顯示完徹底全分離.

基於這樣的新趨勢, 各路大仙紛紛推出了本身的mvvm框架, 好比瀏覽器領域的vue,react和angular, 可是很遺憾的是dom自己還不能完美支持mvvm, 目前想要使用只能藉助框架, 另外一個後起之秀Qt則原生支持了數據綁定, 相信瀏覽器也會慢慢的支持..

 

平行層的多元化

目前爲止, 大勢已定: 前端mvvm, 後端mvc, 中間restful成爲每家每戶的必備工具, 可是這個大致架構下的內部架構是能夠根據不一樣的業務而定製的, 所以出現了不少'平行層', 好比和數據訪問層平行的模型層, 和入口文件平行的配置文件, 還有和其餘輔助類平行的工具層, 所以真正項目中的層次是不止3層的, 固然這就徹底沒有規範了, 仍是根據實際狀況而定吧.

模塊化編程統一每一層的細節

最後我想談談, 在代碼規範上, 咱們主要遵循一種叫模塊化編程的設計規範, 在JavaScript中體現爲函數式編程風格, 模塊化的本質上雖然是'分離', 但效果上卻把零碎的邏輯整合到一塊兒, 更利於開發者思考.

UI設計模式

爲了讓用戶更好的理解UI的功能, 在UI設計上最好也遵照主流的設計模式好比alphabet的material和microsoft的universal等.

項目構建模式

隨着項目構建發佈的流程日趨複雜, 在構建(building)領域也正在造成統一的規範, 固然如今8102年尚未造成...那就不談了吧, 但要意識到這個趨勢

 

 

設計模式的"隱患"

並非說遵照主流設計模式就百利而無一害, 設計模式都是有代價的, 咱們瞭解一下就好:

1. 高可擴展性會犧牲高內聚低耦合度

設計模式幾乎都體現了高可擴展性, 覺得能夠知足性的需求, 可是仔細想一想可擴展意味着接口預留豐富, 層次劃分多級, 整個系統的體積也會很大, 天然會致使內聚性的下降, 性能的衰減, 固然不少狀況下這是不可避免的, 咱們仍然選擇了犧牲硬件成原本保證邏輯上的安全, 畢竟硬件資源愈來愈廉價.

 

2. 讓你變得更懶惰:)

項目一上手就急着找相關的設計模式, 必定程度上減小了本身思考的時間, 同時, 設計模式在實際狀況上的實現也有無數種方案, 若是新人一開始直接照搬別人的模式拒絕本身思考, 甚至不理解整個模式的工做流程, 這該是一件多麼可怕的事情.

 

3. 選擇錯誤的代價

設計模式雖然讓你的項目更易修改, 但若是你想更換整個設計模式就是件很痛苦的事情了, 若是你發現整個系統從一開始就設計失誤, 不只往後再難微調, 還會形成極大的安全隱患. 因此個人建議是, 若是你是新手, 或者你對一個全新的設計模式0瞭解, 那就不要急着上手, 學會先思考, 針對目前的項目設計一個本身的設計模式, 思考的同事考慮擴展性, 可讀性, 功能性, 性能等因素, 以後再拿這個本身的設計模式到互聯網上尋找相似的模式, 或者像前輩請教, 若是發現了一個形態不一樣但本質同樣的設計思想或者看到了更好的解決方案, 那就說明你成功了.

相關文章
相關標籤/搜索