前端MVC框架Backbone 1.1.0源碼分析(一)

 

前言

如何定義庫與框架

前端的輔助工具太多太多了，那麼咱們是如何定義庫與框架？

• jQuery是目前用的最廣的庫了，可是總體來說jQuery目的性很也明確針對「DOM操做」，固然本身寫一個原生態方法也能實現一樣的DOM操做，換句話說，無論你用來仍是不用，都不影響你總體的佈局，或者是代碼體系結構。
• 框架則是一套完整的解決方案，針對是某一個領域的，好比EXT，dojo，那麼很明顯，你要用就須要按照它的規則執行，不論是編碼風格仍是結構，有必定的約束力

 

---

一個老話題，前端爲何要用MVC

• 前端開發中呢，不可避免的都有在應用邏輯中加入顯示數據的代碼的狀況，當項目規模愈發變大時，這種形式的代碼變得愈加的難以維護，由於任何在主幹邏輯中的變動均可能影響到數據顯示邏輯，反之亦然，固然無論什麼模式最主要的仍是分離職責
• 可能在大多數後端開發者看來，整個前端就是一個View層罷了，還在在這個View層中劃分模型，控制器等等，是否是很不屑？
• 在幾年前只作作網站的驗證之類的功能的話我或許會說，是的那是我也不信，可是隨着Web前端隨着複雜度的增長，不少地方跟客戶端已經沒有本質區別了。
• 若是是單純的頁面型的產品，確實不須要那麼複雜，編程嘛複雜便是錯，針對不一樣項目咱們應該就要明確不一樣的方案，就拿近幾年出現的Hybird App來講，這種應用軟件類產品，這就太需有良好的結構組織了，深有感觸的是我本身手上就是Hybird App這種項目，基本都是AMD+各類設計模式的組合

 

---

此MVC非比MVC

• MVC，模型 - 視圖 - 控制器這個沒哈好說的，基本概念你們都知道，PHP的zend,yii不少都是基於MVC的架構，可是這種的架構實際上是把整個前端都都做爲一個view處理了
• 因此若是單純拿Smalltalk-80的MVC的概念去套用前端，也就不那麼合適了

 

---

咱們如何理解前端的MVC

前端架構出現的根本緣由呢，前端被愈來愈重視，nodejs,混合應用相似phonegap這都是在侵佔別的領域 - -，因此前端功能的加強、代碼的膨脹，致使不得不作「前端的架構」這個事情了。

軟件架構模式MVC(Model-View-Controller)

大概理解就是：Models用來處理數據，View將處理結果呈現給用戶，Controller用來鏈接這二者。

因此整個流程：

• 用戶在View上進行操做——好比在文本框輸入數值或是點擊按鈕
• Controller處理這個動做
• Controller經過Model對數據進行增刪改查，將其傳遞到View
• View將數據展現給用戶

 

大多數的前端jser感覺不到MVC的重要性，最大的問題仍是跟傳統的觀念有差異，模型不夠複雜，不存在控制器的概念

固然直接說前端MVC仍是有點牽強的，模型不是真正的模型，在操做View的過程當中一些輔助的模型，真正的Model是貫穿先後端的

歸根結底，我也不須要太深刻的去討論各類不一樣，可是前端MVC框架的出現帶來的是一整套工做流程變動，後端工程師也能夠編寫前端的模型代碼，把它跟後端完全打通，交互工程師處理UI跟模型的互動關係，UI工做人員能夠專一、無障礙地處理HTML源碼，把它們以界面模版的形式提供給交互工程師。這一整套協做機制可以大大提升B/S架構系統的開發效率，若是再有外圍的管控平臺，生產效率將真正踏進工業化的階段。

 

---

backbone

backbone是什麼？

Backbone.js 是一個在JavaScript環境下的 模型-視圖-控制器 (MVC) 框架。任何接觸較大規模項目的開發人員必定會苦惱於各類瑣碎的事件回調邏輯、以及金字塔般的代碼。並且，在傳統的Web應用程序代碼中，不可避免的都有在應用邏輯中加入顯示數據的代碼的狀況。當項目規模愈發變大時，這種形式的代碼變得愈加的難以維護，由於任何在主幹邏輯中的變動均可能影響到數據顯示邏輯，反之亦然。

Backbone就是要來解決這樣的代碼耦合的問題。它經過提供一個控制層-顯示層的框架，以及模版(template)來分離各自邏輯。這樣的MVC框架相似於傳統意義上桌面程序以及服務器端程序的程序框架。

這裏只提backbone，至於什麼mvp,mvvc模式，Angular,Ember,CanJs,我也研究不是很深刻，就不誤人子弟了

模型、視圖、集合和路由器是 Backbone 框架中的主要組件

在backbone框架中，咱們看不到控制器這個東東，在0.5版本以前好像是叫控制器，後來改爲路由器了

可見backbone雖然號稱MVC，可是也非正統啊

總的理解

模型Models進行數據處理，建立驗證銷燬或者保存到服務器

合集Collections用來枚舉

經過Views來進行事件處理及與現有的Application經過RESTful JSON接口進行交互

backbone基本概念很容易理解，可是它並不會告訴你如何去架構一個應用，而僅僅只是在代碼的邏輯組織上提供一種方案

因此正真把backbone用好，我的感受難度仍是比其他的一些框架要大不少

並且還有個最大的問題，結構冗餘，Backbone要求你寫不少樣板代碼，而這種代碼其實不少時候是徹底不必的

好處天然就是靈活，社區大，插件多了

 

---

官方todos

http://backbonejs.org/examples/todos/index.html

這是個很經典的案例

先看todos須要實現的功能

1 添加任務

2 修改任務

3 刪除任務

4 任務統計

這個是徹底用backbone實現的，其實總體一看邏輯仍是很清晰的

Model，Collection，View，View

 

---

backbone的實現

先來分解下todos的操做，經過用戶輸入信息，而後顯示信息到頁面，而後還能夠刪除修改

視圖View寓意就很明確，展示內容，內容從哪裏來的，模型裏面取的，模型爲何會有數據，由於用戶輸入的，怎麼知道用戶輸入，由於監聽了

咱們看看backbone的作法

首先是建立一個全局的Todo的collection對象

var Todos = new TodoList;

 

在視圖層對用戶行爲的監控，從而對模型合集進行curd的一系列操做

Backbone.View.extend = {
        events: {
            "keypress #new-todo": "createOnEnter",
            "click #clear-completed": "clearCompleted",
            "click #toggle-all": "toggleAllComplete"
        }, 
        createOnEnter: function (e) {
            if (e.keyCode != 13) return;
            if (!this.input.val()) return;

            Todos.create({title: this.input.val()});
            this.input.val('');
        }
    }

若是按照MVC的最原始定義，view永遠不會知道用戶輸入，好比鼠標操做和按鍵，因此這裏很明顯就違規了~~

因此在web開發中，咱們是沒法1：1的對應入座的，用戶的輸入必須經過監聽窗口、文檔和元素上的事件來得到

這裏有個很MVC架構很不明確的點，控制器在哪裏？Controller應該是View操做Model的中介？

因此backbone其實只能是看做爲數據和邏輯相互分離的一種方案，減小代碼開發過程當中的數據和邏輯混亂

好吧我的看法~ 不喜勿噴~

 

附上：

 Developing Backbone.js Applications