聊聊MVC和模塊化以及MVVM和組件化

原文來自 小寒的博客

面向對象，模塊化和MVC

面向對象是指把寫程序映射到現實生活，從而一來邏輯性更強，更容易寫好代碼，二來代碼很貼切，通俗易懂，更被人理解，三來更加容易拓展和管理代碼。

咱們的代碼設計應該有不少人，事物和場景，人是管理員，事物是數據庫，場景就是業務。

面向對象

寫代碼就像在模擬現實的生活的處理公務，好比咱們能夠抽象出一些人幫咱們來幹活。

文章管理員，負責文章的CRUD，文章分類的CRUD

用戶管理員，oauth passport和CRUD

郵件管理員，send email，郵件模版的CRUD

短信管理員，send SMS，短信模板的CRUD

消息管理員，send notification，站內和站外消息模版的CRUD

還有客戶端管理員，交易管理員等等等等。。。

分佈式開發中，還會借用一些其餘服務器的管理員。

固然這裏抽象出來多個管理員，還能夠抽象出文章存儲室，用戶信息存儲室這樣的被管理的對象。

模塊化

把代碼按照功能和數據分紅多個模塊，文章模塊，用戶模塊，郵件模塊等等，一個模塊可能對應多個管理員，好比文章模塊裏他可能有文章分類管理員，文章管理員，文章查看歷史管理員。

模塊能夠理解爲這個世界上有不一樣的行業，也能夠理解爲一個家裏也有不一樣的分工，因此分模塊可大可小，能夠在大的模塊裏去區分子模塊。總之模塊是爲了解決業務的耦合。就像分行業也是爲了解決社會的耦合，但模塊之間並不會區分的很完全，就像各行各業總會有所關聯，因此這也須要程序設計者們把握好度了。

模塊之間的管理員之間是除了有分工以外，還有很大的合做。好比2C的應用裏用戶管理員老是須要忙個不停，由於他總要跑來跑去的幫助其餘模塊去識別用戶

咱們實現一個很複雜的功能，需求是這樣的

某用戶的博客發佈以後須要其餘的人登錄後才能夠查看，查看的時候會給博客做者發個短信，告訴博主有人來看你的短信了，再給來看博客的人發個郵件說歡迎光臨。

1. user = await UserManager.getByToken(req.header.token)
2. if (user) blog = await BlogManager.getById(req.params.blogId)
3. res.send(blog) 
    && SMSManager.send(blog.author.phone, 'blog-be-read')
    && EmailManager.send(user.email, 'welcome')複製代碼

MVC

這裏呢UserManager BlogManager SMSManager EmailManager都是controller，理解爲控制數據。

res.send(blog) 中的blog是view，能夠理解爲要呈現給前端的東西。

這些管理圓管理的模版和數據庫則屬於model，能夠理解爲原始的數據。

mvc是應對複雜業務場景的後臺最多見的設計模式，會把程序抽象成三層，就像在面向對象裏說的那樣，一個程序應該有人，事物，業務，其實也能夠理解爲人就是controller，事物是model，業務是view。對於web後端來講view常常會是web前端。

前端的MVC

類比於後端的MVC

在前端

M指的是後臺給的數據，即原始數據

V仍然是要呈現的數據，可是是呈現給用戶的界面

C值得是處理後臺的數據和view層的交互邏輯

具體實現呢

// model
model = res.data

// controller
view.date = Formater.formatTime(model.date)
view.author = Formater.formatUserName(model.author)
view.blog = BlogController.beautify(model.blog)

// view
document.write(view.author)
document.write(view.date)
document.write(view.blog)複製代碼

document.write相對於res.send是同樣的

前端也會有一些工做人員好比 Formater, BlogController也是控制數據的

是否是和後端很像呀

不一樣的是前端的view很複雜model很簡單，後端的model很複雜view很簡單。

前端對MVC的不足

前端的view可能只是在展現數據，這樣的網站很適合用MVC，好比管理系統，一個頁面一個table的那種。

但也極可能很是複雜，好比在2C的程序中頁面可能要肩負各類複雜的操做，操做太瑣碎，controller就會變得很臃腫。好比說這個網站裏的音樂播放器，要有

上一首，下一首，隨機播放，單曲循環，音量，顯示列表，顯示歌詞，關閉歌詞，顯示列表，選擇歌曲，關閉列表，暫停，繼續，快進，快退，更新播放時間等等等等的功能。。。這個時候功能這些功能要所有寫在controller裏同時還要發起請求更新數據，監聽時間變化，controller就很複雜。

咱們一般都是請求一次後臺，而後塞一個列表進去，而後用戶切換音樂只是在本地內存裏讀取數據。

這個時候就會有問題

1. 前端的複雜的操做不像後塊化那樣能夠解耦，前端頁面之間，組件之間的耦合應該如何處理

2. 前端的複雜的操做太多了，controller要處理事件還要處理請求，如何減輕維護controller的成本

3. 單頁面應用中須要在前端維護一份數據，這份數據只是臨時的，不能夠放在後端的model裏應該放在哪

同時咱們也會發現，複雜的業務場景裏view和controller的事件處理部分邏輯關係至關密切，因此開發者常常會把controller和view封裝在一塊兒，這個時候就出現了組件。

而開發者會在前端暫存一封數據，由於瀏覽器不用常常刷新了，不須要常常發起請求，所以出現了vm，意指view model。和model的區別就是他是針對view的model。

就這樣出現了mvvm和組件化

組件化和MVVM

MVVM

歸根結底的說MVC不適合前端的一些業務場景就是由於後端V會相對簡單，重點在於解決controller和model的關係。前端的V很複雜，重點在於解決view和controller的問題。

在MVVM中

M不變，能夠認爲他是數據來源，M很簡單，但數據每每不是view須要的。

V是UI和用戶輸入。面對複雜的用戶操做並且要迅速給予反饋，操做和展現每每是同時存在的，好比一個表單就確定會有表達數據和接受輸入兩種屬性。這就是組件，組件同時具備兩種能力，接受輸入獲取反饋也是MVVM裏的第二個V。

VM是在單頁應用裏出現的一種概念，在單頁面的應用裏數據在用戶不刷新的狀態下能夠一直暫存在瀏覽器的內存裏，於是把數據請求到本地以後就緩存在客戶端的內存裏，能夠大幅度的複用數據，同時也須要有一層相似於數據庫的VM是專門爲V提供的model，因此他必須給V更加準確和溫馨的數據，以及獲取數據和修改數據的方式。同時VM也要減小V裏複雜的controller裏的api冗餘，避免過於繁重的controller，因此和VM也須要負責發起請求。

最後結論就是。

M是response data

V是view + user action controller

VM是store + request controller

這樣寫的好處有

1. view中加入controller能夠加強組件化，view和controller更加密切，能夠專一的的表達UI和交互邏輯，把前端的任務大幅度專一在用戶體驗和UI構建上。

2. 分離model和view之間的直接聯繫，把和後端交流的任務分配給了view model，確保view拿到的數據更加優雅和易用。

3. 前端暫留一份數據層，供本身的UI使用。同時也把請求數據，處理後臺數據的任務給了vm。大幅度減小了controller裏的代碼。還能起到複用請求和處理數據代碼的好處。

組件化

組件化也是面向對象的一種表現。可是組件化和模塊化開發在感受上會又很大的區別。

組件是一種有着強大功能的 "dom" 元素。

組件的任務是用戶體驗和UI構建。

好比這個博客網站就是由 1. 留言表單 2. 逐個出現的動畫組件，3. 音樂播放器，4. 音樂背景牆和歌詞組件，5. 博客導航菜單組件 6. 歌單組件 7 歌曲組件 8 導航組件 9 底部組件 10 博客內容 11 博客列表 構成。

我羅列了如下，意思就是說這麼大的一個網站其實能夠只是這麼幾個組件而已，這就是組件化的好處。專一構建UI和提高用戶體驗。

前端組件分類

從bootstrap開始組件分類就已經開始了，一般咱們會認爲有

antd分爲通用，佈局，導航，數據錄入，數據展現，反饋和其餘

這個分類很難以辯駁，我的以爲比較合理，可是這種分類的依據很難說的出來。由於上學的時候，書本里的分類前都會說按照XXX分類能夠分爲。可是antd這個分類方法就不容易感知到了。

好比通用和數據錄入顯然並非一種分類方法。通用是表達組件的使用範圍廣度，數據錄入是按照功能劃分的

再好比數據展現和反饋極可能差很少，只是反饋不是直接的數據展現。

但細想如下，這種分類確實也表現出了各個類別裏組件的特色。總之分類只是便於理解。由於分不開呀。

我一般會把組件的做用分爲如下三種

1. 用於數據展現的

2. 用於接受用戶操做的

3. 輔助和加強功能

嚴謹的說這個是分類組件的功能，而不是給組件分類。而幾乎大多數組件都很容易就具備1 2 兩種屬性。並不容易肯定組件屬於某種功能，但能看出他們更傾向於那種。

好比

Collapse就是輔助和功能性的，咱們市面上見到的都是CollapsePanel這個組件，而Panel是展現數據的組件。

Table就是數據展現的，被咱們拓展封裝以後呢，咱們用到的Table極可能是TableWithPagination，這就讓Table就能夠接受用戶輸入了。但Table是更傾向於展現數據的組件

Button是更傾向於用戶操做的組件，由於他很能展現文字。

因此能夠發現咱們用到的組件大多都是有不一樣的屬性的，就像問道里的人物角色同樣，三敏一體一力 什麼什麼的，就是敏捷型的角色。

網站自己是傾向於數據展現的一種應用。所以有些也很差歸類爲更傾向於某種功能，篇幅有限，總之這個話題想要獲得一個比較妥善的答案能夠討論幾千字吧。

React不是框架

React是一個構造可組合式用戶界面的庫，它鼓勵建立可重用的UI組件去顯示會隨着時間而改變的數據。

不少人寫react的出發點是錯的，和angular，vue出發點並不相同。facebook發明react的緣由是在富交互時代的web開發中，如何更好的組織UI是一個很棘手的問題，而經過組件的方式能夠很好的解決了這個問題，因此發明了react。

因此說白了react只是一個解決UI問題的工具庫而已，使用這個庫咱們能夠很方便的構建一些複雜的交互和樣式，並把網站抽象成一個個組件，而後簡化web UI的開發，而配合這個庫使用解決其餘問題的好比react-redux，

react-router等等則是解決web開發的除了UI之外的數據管理和路由等問題的。

若是不能抽象UI，那麼用react可能對你來講並不合適甚至極可能是一種累贅，用vue或者ng能夠大幅度減小代碼量

參考連接：

爲何咱們要造React？

維基百科MVC

MVVM是什麼？