前端框架综述(8)前端
1 前端到底有什么
??學習完了基本都HTML組件,CSS樣式,以及JavaScript之后,我們就可以編寫一個簡單的用于給用戶觀看的視圖層頁面了,但是,現在網絡中又出現了各種各樣的前端框架又是用來做什么的呢?
??現在前端各種各樣,處于一個百家爭鳴的情況,所以現在很多學習前端的人不知道到底應該學習哪一個框架,下面就針對現在前端的整體情況進行宏觀描述。
??其實,前端的底層就只有HTML,CSS和JavaScript構成,但是由于每一次構建一個簡單的網頁都要付出很大的時間成本,另外因為項目的愈發龐大,所以就有各種大神用各種可以工程化的框架來封裝它們,這樣我們以后想要寫出一個精美漂亮的,雖然頁面或者內容多但是結構清晰便于維護的前端代碼就變得更加簡單了。
??因此,所有各種各樣的框架都是在不停的封裝封裝再封裝從而形成了各自的不同的框架,形成了框架非常多,導致學習者不知道應該學習哪一個。但是了解了本質之后,其實可以學會了一兩種框架之后,由于各個框架要做的事情都差不多,所以在遷移學習其他框架就會變得異常簡單。
??框架大體分為三種:
(1)一種是對CSS封裝的框架,
(2)一種是對javascript封裝的框架,當然,html都蘊含在兩者其中。
(3)還有就是一種是對前端項目進行包管理的框架(類似于java中的maven)。
1.1 對CSS封裝最流行的框架
??也就是所謂的UI框架,目前非常多:
Ant-Design:阿里巴巴出品,基于 React 的 UI 框架
ElementUI、iview、ice:餓了么出品,基于 Vue 的 UI 框架
Bootstrap:Twitter 推出的一個用于前端開發的開源工具包
AmazeUI:又叫“妹子 UI”,一款 HTML5 跨屏前端框架
Layui:輕量級框架
1.1.1 iview(主流)
??iview 是一個強大的基于 Vue 的 UI 庫,有很多實用的基礎組件比 elementui 的組件更豐富,主要服務于PC 界面的中后臺產品。使用單文件的 Vue 組件化開發模式 基于 npm + webpack + babel 開發,支持ES2015 高質量、功能豐富 友好的 API ,自由靈活地使用空間。
????官網地址: https://www.iviewui.com/
????Github: https://github.com/TalkingData/iview-weapp
????iview-admin:https://github.com/iview/iview-admin
1.1.2 ElementUI(主流)
??Element 是餓了么前端開源維護的 Vue UI 組件庫,組件齊全,基本涵蓋后臺所需的所有組件,文檔講解詳細,例子也很豐富。主要用于開發 PC 端的頁面,是一個質量比較高的 Vue UI 組件庫。
????官網地址:http://element-cn.eleme.io/#/zh-CN
????Github: https://github.com/ElementUI/element-starter
????iview-admin:https://github.com/PanJiaChen/vue-element-admin
1.1.3 ICE(觀望階段):
??飛冰是阿里巴巴團隊基于 React/Angular/Vue 的中后臺應用解決方案,在阿里巴巴內部,已經有 270 多個來自幾乎所有 BU 的項目在使用。飛冰包含了一條從設計端到開發端的完整鏈路,幫助用戶快速搭建屬于自己的中后臺應用。(主要組件還是以 React 為主,截止 2019 年 02 月 17 日更新博客前對 Vue 的支持還不太完善,目前尚處于觀望階段)
????官網地址:https://alibaba.github.io/ice
????Github:https://github.com/alibaba/ice
1.1.4 VantUI:
??Vant UI 是有贊前端團隊基于有贊統一的規范實現的 Vue 組件庫,提供了一整套 UI 基礎組件和業務組件。通過 Vant,可以快速搭建出風格統一的頁面,提升開發效率。
????官網地址:https://youzan.github.io/vant/#/zh-CN/intro
????Github:https://github.com/youzan/vant
1.1.5 AtUI:
??at-ui 是一款基于 Vue 2.x 的前端 UI 組件庫,主要用于快速開發 PC 網站產品。 它提供了一套 npm +webpack + babel 前端開發工作流程,CSS 樣式獨立,即使采用不同的框架實現都能保持統一的 UI 風格。
????官網地址:https://at-ui.github.io/at-ui/#/zh
????Github:https://github.com/at-ui/at-ui
1.1.6 CubeUI
??cube-ui 是滴滴團隊開發的基于 Vue.js 實現的精致移動端組件庫。支持按需引入和后編譯,輕量靈活;擴展性強,可以方便地基于現有組件實現二次開發。
????官網地址:https://didi.github.io/cube-ui/#/zh-CN
????Github:https://github.com/didi/cube-ui/
1.1.7 Flutter
??Flutter 是谷歌的移動端 UI 框架,可在極短的時間內構建 Android 和 iOS 上高質量的原生級應用。Flutter 可與現有代碼一起工作, 它被世界各地的開發者和組織使用, 并且 Flutter 是免費和開源的。(Google 出品,主要特點是快速構建原生 APP 應用程序,如做混合應用該框架為必選框架)
????官網地址:https://flutter.dev/docs
????Github:https://github.com/flutter/flutter
1.1.8 Ionic
??Ionic 既是一個 CSS 框架也是一個 Javascript UI 庫,Ionic 是目前最有潛力的一款 HTML5 手機應用開發框架。通過 SASS 構建應用程序,它提供了很多 UI 組件來幫助開發者開發強大的應用。它使用JavaScript MVVM 框架和AngularJS/Vue 來增強應用。提供數據的雙向綁定,使用它成為 Web 和移動開發者的共同選擇。
????官網地址:https://ionicframework.com/
????官網文檔:https://ionicframework.com/docs/
????Github:https://github.com/ionic-team/ionic
1.1.9 mpvue
??mpvue 是美團開發的一個使用 Vue.js 開發小程序的前端框架,目前支持 微信小程序、百度智能小程序,頭條小程序 和 支付寶小程序。 框架基于 Vue.js,修改了的運行時框架 runtime 和代碼編譯器compiler 實現,使其可運行在小程序環境中,從而為小程序開發引入了 Vue.js 開發體驗。
(完備的 Vue 開發體驗,并且支持多平臺的小程序開發,推薦使用)
????官網地址:http://mpvue.com/
????Github:https://github.com/Meituan-Dianping/mpvue
1.1.10 WeUI
??WeUI 是一套同微信原生視覺體驗一致的基礎樣式庫,由微信官方設計團隊為微信內網頁和微信小程序量身設計,令用戶的使用感知更加統一。包含 button、cell、dialog、toast、article、icon 等各式元素。
????官網地址:https://weui.io/
????Github:https://github.com/weui/weui.git
1.2 對JavaScript封裝的框架最流行的有
1.2.1 jQuery庫
??大家最熟知的 JavaScript 庫,優點是簡化了 DOM 操作,缺點是 DOM 操作太頻繁,影響前端性能;在前端眼里使用它僅僅是為了兼容 IE6、7、8;
1.2.2 Angular
??Google 收購的前端框架,由一群 Java 程序員開發,其特點是將后臺的 MVC 模式搬到了前端并增加了模塊化開發的理念,與微軟合作,采用 TypeScript 語法開發;對后臺程序員友好,對前端程序員不太友好;最大的缺點是版本迭代不合理(如:1代 -> 2代,除了名字,基本就是兩個東西;已推出了Angular6)
1.2.3 React
??Facebook 出品,一款高性能的 JS 前端框架;特點是提出了新概念 【虛擬 DOM】 用于減少真實 DOM操作,在內存中模擬 DOM 操作,有效的提升了前端渲染效率;缺點是使用復雜,因為需要額外學習一門 【JSX】 語言
1.2.4 Vue(目前最流行)
??一款漸進式 JavaScript 框架,所謂漸進式就是逐步實現新特性的意思,如實現模塊化開發、路由、狀態管理等新特性。其特點是綜合了 Angular(模塊化) 和 React(虛擬 DOM) 的優點;
1.2.5 Axios
??前端通信框架;因為 Vue 的邊界很明確,就是為了處理 DOM,所以并不具備通信能力,此時就需要額外使用一個通信框架與服務器交互;當然也可以直接選擇使用 jQuery 提供的 AJAX 通信功能;
1.2.6 javaScrit概述
??JavaScript 一門弱類型腳本語言,其源代碼在發往客戶端運行之前不需經過編譯,而是將文本格式的字符代碼發送給瀏覽器由瀏覽器解釋運行。
??原生 JS 開發,也就是讓我們按照 【ECMAScript】 標準的開發方式,簡稱是 ES,特點是所有瀏覽器都支持。??ES 標準已發布如下版本:
????ES3
????ES4(內部,未正式發布)
????ES5(全瀏覽器支持)
????ES6(常用,當前主流版本:webpack打包成為ES5支持!)
????ES7
????ES8
????ES9(草案階段)
??從 ES6 開始每年發布一個版本,以年份作為名稱,區別就是逐步增加新特性。
1.2.7 TypeScript
??TypeScript 是一種由微軟開發的自由和開源的編程語言。它是 JavaScript 的一個超集,而且本質上向這個語言添加了可選的靜態類型和基于類的面向對象編程。由安德斯·海爾斯伯格(C#、Delphi、 TypeScript 之父;.NET 創立者)主導。
1.3 CSS預處理器和JavaScript構建工具
- 什么是CSS預處理器
??CSS 層疊樣式表是一門標記語言,并不是編程語言,因此不可以自定義變量,不可以引用等,換句話說就是不具備任何語法支持,它主要缺陷如下:
(1)語法不夠強大,比如無法嵌套書寫,導致模塊化開發中需要書寫很多重復的選擇器;
(2)沒有變量和合理的樣式復用機制,使得邏輯上相關的屬性值必須以字面量的形式重復輸出,導致難
以維護;
??這就導致了我們在工作中無端增加了許多工作量。為了解決這個問題,前端開發人員會使用一種稱之為【CSS 預處理器】 的工具,提供 CSS 缺失的樣式層復用機制、減少冗余代碼,提高樣式代碼的可維護性。大大提高了前端在樣式上的開發效率。
??CSS 預處理器定義了一種新的語言,其基本思想是,**用一種專門的編程語言,為 CSS 增加了一些編程的特性,將 CSS 作為目標生成文件,然后開發者就只要使用這種語言進行 CSS 的編碼工作。**轉化成通俗易懂的話來說就是“用一種專門的編程語言,進行 Web 頁面樣式設計,再通過編譯器轉化為正常的 CSS 文件,以供項目使用”。
??常用的 CSS 預處理器有SASS和LESS
(1)SASS:基于 Ruby,通過服務端處理,功能強大。解析效率高。需要學習 Ruby 語言,上手難度高于 LESS。
(2)LESS:基于 NodeJS,通過客戶端處理,使用簡單。功能比 SASS 簡單,解析效率也低于 SASS,但在實際開發中足夠了,所以我們后臺人員如果需要的話,建議使用 LESS。 - 什么是JavaScript構建工具
??一個是因為有些瀏覽器不支持某個版本的es版本,所以要進行降級處理,可以利用某個工具把高版本語法代碼的JavaScript轉變成低版本語法的代碼。另一個則是為了方便打包等基礎功能。目前使用的是Babel和WebPack工具
(1)Babel:JS 編譯工具,主要用于瀏覽器不支持的 ES 新特性,比如用于編譯 TypeScript
(2)WebPack:模塊打包器,主要作用是打包、壓縮、合并及按序加載
1.4 前端所需要的后端技術
??前端人員為了方便開發也需要掌握一定的后端技術,但我們 Java 后臺人員知道后臺知識體系極其龐大復雜,所以為了方便前端人員開發后臺應用,就出現了 NodeJS 這樣的技術。
??NodeJS 的作者已經聲稱放棄 NodeJS(說是架構做的不好再加上笨重的 node_modules,可能讓作者不爽了吧),開始開發全新架構的 Deno。
??既然是后臺技術,那肯定也需要框架和項目管理工具,NodeJS 框架及項目管理工具如下:
(1)Express:NodeJS 框架
(2)Koa:Express 簡化版
(3)NPM:項目綜合管理工具,類似于 Maven
(4)YARN:NPM 的替代方案,類似于 Maven 和 Gradle 的關系
2 前端行業情況
??前端工程師“Front-End-Developer”源自于美國。大約從2005年開始正式的前端工程師角色被行業所認可,到了2010年,互聯網開始全面進入移動時代,前端開發的工作越來越重要。
??最初所有的開發工作都是由后端工程師完成的,隨著業務越來越繁雜,工作量變大,于是我們將項目中的可視化部分和一部分交互功能的開發工作剝離出來,形成了前端開發。
??由于互聯網行業的急速發展,導致了在不同的國家,有著截然不同的分工體制。
??在日本和一些人口比較稀疏的國家,例如加拿大、澳洲等,流行“Full-Stack Engineer”,也就是我們通常所說的全棧工程師。通俗點說就是一個人除了完成前端開發和后端開發工作以外,有的公司從產品設計到項目開發再到后期運維可能都是同一個人,甚至可能還要負責UI、配動畫,也可以是掃地、擦窗、寫文檔、維修桌椅等等。而在美國等互聯網環境比較發達的國家項目開發的分工協作更為明確,整個項目開發分為前端、中間層和后端三個開發階段,這三個階段分別由三個或者更多的人來協同完成。
??國內的大部分互聯網公司只有前端工程師和后端工程師,中間層的工作有的由前端來完成,有的由后端來完成。
??PRD(產品原型-產品經理) - PSD(視覺設計-UI工程師) - HTML/CSS/JavaScript(PC/移動端網頁,實
現網頁端的視覺展示和交互-前端工程師)
3 前后端分離的演變史
3.1 后端為主的MVC時代
??為了降低開發的復雜度,以后端為出發點,比如:Struts、SpringMVC 等框架的使用,就是后端的 MVC
時代;
以 SpringMVC 流程為例:
- 發起請求到前端控制器( DispatcherServlet )
- 前端控制器請求 HandlerMapping 查找 Handler ,可以根據 xml 配置、注解進行查找
- 處理器映射器 HandlerMapping 向前端控制器返回 Handler
- 前端控制器調用處理器適配器去執行 Handler
- 處理器適配器去執行 Handler
- Handler 執行完成給適配器返回 ModelAndView
- 處理器適配器向前端控制器返回 ModelAndView , ModelAndView 是 SpringMVC 框架的一個底層對象,包括 Model 和 View
- 前端控制器請求視圖解析器去進行視圖解析,根據邏輯視圖名解析成真正的視圖( JSP )
- 視圖解析器向前端控制器返回 View
- 前端控制器進行視圖渲染,視圖渲染將模型數據(在 ModelAndView 對象中)填充到 request 域
- 前端控制器向用戶響應結果
優點:
??MVC 是一個非常好的協作模式,能夠有效降低代碼的耦合度,從架構上能夠讓開發者明白代碼應該寫在哪里。為了讓 View 更純粹,還可以使用 Thymeleaf、Freemarker 等模板引擎,使模板里無法寫入 Java代碼,讓前后端分工更加清晰。
缺點:
??前端開發重度依賴開發環境,開發效率低,這種架構下,前后端協作有兩種模式:
??1、第一種是前端寫 DEMO,寫好后,讓后端去套模板。好處是 DEMO 可以本地開發,很高效。不足是還需要后端套模板,有可能套錯,套完后還需要前端確定,來回溝通調整的成本比較大;
??2、另一種協作模式是前端負責瀏覽器端的所有開發和服務器端的 View 層模板開發。好處是 UI 相關的代碼都是前端去寫就好,后端不用太關注,不足就是前端開發重度綁定后端環境,環境成為影響前端開發效率的重要因素。
??前后端職責糾纏不清:模板引擎功能強大,依舊可以通過拿到的上下文變量來實現各種業務邏輯。這樣,只要前端弱勢一點,往往就會被后端要求在模板層寫出不少業務代碼。還有一個很大的灰色地帶是Controller ,頁面路由等功能本應該是前端最關注的,但卻是由后端來實現。 Controller 本身與 Model 往往也會糾纏不清,看了讓人咬牙的業務代碼經常會出現在 Controller 層。這些問題不能全歸結于程序員的素養,否則 JSP 就夠了。
??對前端發揮的局限性:性能優化如果只在前端做空間非常有限,于是我們經常需要后端合作;
注意:在這期間(2005 年以前),包括早期的 JSP、PHP 可以稱之為 Web 1.0 時代。在這里想說一句,如果你是一名 Java 初學者,請你不要再把一些陳舊的技術當回事了,比如 JSP,因為時代在變、技術在變、什么都在變(引用扎克伯格的一句話:唯一不變的是變化本身);當我們去給大學做實訓時,有些同學會認為我們沒有講什么 干貨 ,其實不然,只能說是你認知里的干貨對于市場來說早就過時了而已。
3.2 基于AJAX的SPA時代
??時間回到 2005 年 AJAX (Asynchronous JavaScript And XML,異步 JavaScript 和 XML,老技術新用法) 被正式提出并開始使用 CDN 作為靜態資源存儲,于是出現了 JavaScript 王者歸來(在這之前JS 都是用來在網頁上貼狗皮膏藥廣告的)的 SPA(Single Page Application)單頁面應用時代。
優點:
??這種模式下,前后端的分工非常清晰,前后端的關鍵協作點是 AJAX 接口。看起來是如此美妙,但回過頭來看看的話,這與 JSP 時代區別不大。復雜度從服務端的 JSP 里移到了瀏覽器的 JavaScript,瀏覽器端變得很復雜。類似 Spring MVC,這個時代開始出現瀏覽器端的分層架構:
缺點:
??前后端接口的約定: 如果后端的接口一塌糊涂,如果后端的業務模型不夠穩定,那么前端開發會很痛苦;不少團隊也有類似嘗試,通過接口規則、接口平臺等方式來做。有了和后端一起沉淀的 接口規則,還可以用來模擬數據,使得前后端可以在約定接口后實現高效并行開發。
??前端開發的復雜度控制: SPA 應用大多以功能交互型為主,JavaScript 代碼過十萬行很正常。大量JS 代碼的組織,與 View 層的綁定等,都不是容易的事情。
3.3 前端為主的MV*時代
??此處的 MV* 模式如下:
- MVC(同步通信為主):Model、View、Controller
- MVP(異步通信為主):Model、View、Presenter
- MVVM(異步通信為主):Model、View、ViewModel
??為了降低前端開發復雜度,涌現了大量的前端框架,比如: AngularJS 、 React 、 Vue.js 、 EmberJS 等,這些框架總的原則是先按類型分層,比如 Templates、Controllers、Models,然后再在層內做切分,如下圖:
優點:
??前后端職責很清晰: 前端工作在瀏覽器端,后端工作在服務端。清晰的分工,可以讓開發并行,測試數據的模擬不難,前端可以本地開發。后端則可以專注于業務邏輯的處理,輸出 RESTful等接口。
??前端開發的復雜度可控: 前端代碼很重,但合理的分層,讓前端代碼能各司其職。這一塊蠻有意思的,簡單如模板特性的選擇,就有很多很多講究。并非越強大越好,限制什么,留下哪些自由,代碼應該如何組織,所有這一切設計,得花一本書的厚度去說明。
??部署相對獨立: 可以快速改進產品體驗
缺點:
??代碼不能復用。比如后端依舊需要對數據做各種校驗,校驗邏輯無法復用瀏覽器端的代碼。如果可以復用,那么后端的數據校驗可以相對簡單化。
??全異步,對 SEO 不利:往往還需要服務端做同步渲染的降級方案。
??性能并非最佳:特別是移動互聯網環境下。
??SPA 不能滿足所有需求:依舊存在大量多頁面應用。URL Design 需要后端配合,前端無法完全掌控。
3.4 NodeJS帶來的全棧時代
??前端為主的 MV* 模式解決了很多很多問題,但如上所述,依舊存在不少不足之處。隨著 NodeJS 的興起,JavaScript 開始有能力運行在服務端。這意味著可以有一種新的研發模式:
在這種研發模式下,前后端的職責很清晰。對前端來說,兩個 UI 層各司其職:
- Front-end UI layer 處理瀏覽器層的展現邏輯。通過 CSS 渲染樣式,通過 JavaScript 添加交互功能,HTML 的生成也可以放在這層,具體看應用場景。
- Back-end UI layer 處理路由、模板、數據獲取、Cookie 等。通過路由,前端終于可以自主把控URL Design,這樣無論是單頁面應用還是多頁面應用,前端都可以自由調控。后端也終于可以擺脫對展現的強關注,轉而可以專心于業務邏輯層的開發。
??通過 Node,Web Server 層也是 JavaScript 代碼,這意味著部分代碼可前后復用,需要 SEO 的場景可以在服務端同步渲染,由于異步請求太多導致的性能問題也可以通過服務端來緩解。前一種模式的不足,通過這種模式幾乎都能完美解決掉。
??與 JSP 模式相比,全棧模式看起來是一種回歸,也的確是一種向原始開發模式的回歸,不過是一種螺旋
上升式的回歸。
基于 NodeJS 的全棧模式,依舊面臨很多挑戰:
??需要前端對服務端編程有更進一步的認識。比如 TCP/IP 等網絡知識的掌握。
??NodeJS 層與 Java 層的高效通信。NodeJS 模式下,都在服務器端,RESTful HTTP 通信未必高效,通過 SOAP 等方式通信更高效。一切需要在驗證中前行。
??對部署、運維層面的熟練了解,需要更多知識點和實操經驗。
??大量歷史遺留問題如何過渡。這可能是最大最大的阻力。
3.5 小結
??綜上所述,模式也好,技術也罷,沒有好壞優劣之分,只有適合不適合;前后分離的開發思想主要是基于 SoC (關注度分離原則),上面種種模式,都是讓前后端的職責更清晰,分工更合理高效。
4 MVVM模式
??為了方便后續學習Vue框架,Vue框架是目前非常主流的一款前端框架,而Vue使用的就是MVVM模式,下面我們就針對MVVM模式來深入探討:
4.1 什么是MVVM模式
??MVVM(Model-View-ViewModel)是一種軟件架構設計模式,由微軟 WPF(用于替代 WinForm,以前就是用這個技術開發桌面應用程序的)和 Silverlight(類似于 Java Applet,簡單點說就是在瀏覽器上運行的 WPF) 的架構師 Ken Cooper 和 Ted Peters 開發,是一種簡化用戶界面的事件驅動編程方式。 由 John Gossman(同樣也是 WPF 和 Silverlight 的架構師)于 2005 年在他的博客上發表。
??MVVM 源自于經典的 MVC(Model-View-Controller)模式。MVVM 的核心是 ViewModel 層,負責轉
換 Model 中的數據對象來讓數據變得更容易管理和使用,其作用如下:
- 該層向上與視圖層進行雙向數據綁定
- 向下與 Model 層通過接口請求進行數據交互
MVVM 已經相當成熟了,當下流行的 MVVM 框架有 Vue.js , AngularJS 等。
4.2 為什么要使用MVVM模式
MVVM 模式和 MVC 模式一樣,主要目的是分離視圖(View)和模型(Model),有幾大好處:
- 低耦合: 視圖(View)可以獨立于 Model 變化和修改,一個 ViewModel 可以綁定到不同的 View
上,當 View 變化的時候 Model 可以不變,當 Model 變化的時候 View 也可以不變。 - 可復用: 你可以把一些視圖邏輯放在一個 ViewModel 里面,讓很多 View 重用這段視圖邏輯。
- 獨立開發: 開發人員可以專注于業務邏輯和數據的開發(ViewModel),設計人員可以專注于頁
面設計。 - 可測試: 界面素來是比較難于測試的,而現在測試可以針對 ViewModel 來寫。
4.3 MVVM的組成
View:
??View 是視圖層,也就是用戶界面。前端主要由 HTML 和 CSS 來構建,為了更方便地展現ViewModel 或者 Model層的數據,已經產生了各種各樣的前后端模板語言,比如 FreeMarker、Thymeleaf 等等,各大 MVVM 框架如 Vue.js,AngularJS,EJS 等也都有自己用來構建用戶界面的內置模板語言。
Model:
??Model 是指數據模型,泛指后端進行的各種業務邏輯處理和數據操控,主要圍繞數據庫系統展開。這里的難點主要在于需要和前端約定統一的 接口規則。
ViewModel:
??ViewModel 是由前端開發人員組織生成和維護的視圖數據層。在這一層,前端開發者對從后端獲取的Model 數據進行轉換處理,做二次封裝,以生成符合 View 層使用預期的視圖數據模型。
需要注意的是 ViewModel 所封裝出來的數據模型包括視圖的狀態和行為兩部分,而 Model 層的數據模型是只包含狀態的。
- 比如頁面的這一塊展示什么,那一塊展示什么這些都屬于視圖狀態(展示)
- 頁面加載進來時發生什么,點擊這一塊發生什么,這一塊滾動時發生什么這些都屬于視圖行為(交互)
??視圖狀態和行為都封裝在了 ViewModel 里。這樣的封裝使得 ViewModel 可以完整地去描述 View 層。由于實現了雙向綁定,ViewModel 的內容會實時展現在 View 層,這是激動人心的,因為前端開發者再也不必低效又麻煩地通過操縱 DOM 去更新視圖。
??MVVM 框架已經把最臟最累的一塊做好了,我們開發者只需要處理和維護 ViewModel,更新數據視圖就會自動得到相應更新,真正實現 事件驅動編程 。
??View 層展現的不是 Model 層的數據,而是 ViewModel 的數據,由 ViewModel 負責與Model 層交互,這就完全解耦了 View 層和 Model 層,這個解耦是至關重要的,它是前后端分離方案實施的重要一環。
??而Vue做的就是完全封裝了ViewModel層,讓我們只關注View和Model,而數據的交互就完全交給Vue代理。
總結
以上是生活随笔為你收集整理的前端框架综述(8)前端的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 设计简单带通滤波电路
- 下一篇: DTV专业术语