這篇文章將為大家詳細(xì)講解有關(guān)如何理解Backbone.js 的技巧和模式，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對相關(guān)知識(shí)有一定的了解。

公司主營業(yè)務(wù)：成都網(wǎng)站制作、做網(wǎng)站、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)公司推出漳州免費(fèi)做網(wǎng)站回饋大家。

Backbone.js是一個(gè)開源JavaScript“MV*”框架， 在三年前它的第一次發(fā)布的時(shí)候就獲得了顯著的推動(dòng)。盡管Backbone.js為Javascript應(yīng)用程序提供了自己的結(jié)構(gòu)，但它留下了大量根據(jù)開發(fā) 者的需要而使用的設(shè)計(jì)模式和決策，并且當(dāng)開發(fā)者們第一次使用Backbone.js開發(fā)的時(shí)候都會(huì)遇到許多共同的問題。

因此，在這篇文章中，我們除了會(huì)探索各種各樣你能夠應(yīng)用到你的Backbone.js應(yīng)用中的設(shè)計(jì)模式外，我們也會(huì)關(guān)注一些困惑開發(fā)者的常見問題。

執(zhí)行對象的深復(fù)制

JavaScript中所有原始類型變量的傳遞都是值傳遞。所以，當(dāng)變量被引用的時(shí)候會(huì)傳遞該變量的值。

var helloWorld = “Hello World”; var helloWorldCopy = helloWorld;

例如，以上代碼會(huì)將helloWorldCopy 的值設(shè)為helloWorld的值。所以對于helloWorldCopy 的所有修改都不會(huì)改變helloWorld, 因?yàn)樗且粋€(gè)拷貝。另一方面，JavaScript所有非原始類型變量的傳遞都是引用傳遞，意思是當(dāng)變量被引用的時(shí)候，JavaScript會(huì)傳遞一個(gè)其內(nèi)存地址的參照。

var helloWorld = {     ‘hello’: ‘world’ } var helloWorldCopy = helloWorld;

舉個(gè)例子，上面的代碼會(huì)將helloWorldCopy 設(shè)為helloWorld  對象的別名，此時(shí)，你可能會(huì)猜到，對helloWorldCopy 的所有修改都會(huì)直接在helloWorld  對象上進(jìn)行。如果你想得到一個(gè)helloWorld 對象的拷貝，你必須對這個(gè)對象進(jìn)行一次復(fù)制。

你可能想知道，“為什么他（作者）要在這篇文章中解釋這些按引用傳遞的東西？”很好，這是因?yàn)樵?strong>Backbone.js的對象傳遞中，并不對進(jìn)行對象復(fù)制，意味著如果你在一個(gè)模型中調(diào)用 get( ) 方法來取得一個(gè)對象，那么對它的任何修改都會(huì)直接在模型中的那個(gè)對象進(jìn)行操作！讓我們通過一個(gè)例子來看看什么時(shí)候它會(huì)成為你的麻煩。假設(shè)現(xiàn)在你有一個(gè)如下的Person 模型：

var Person = Backbone.Model.extend({    defaults: {         'name': 'John Doe',         'address': {             'street': '1st Street'             'city': 'Austin',             'state': 'TX'             'zipCode': 78701         }    } });

并且假設(shè)你創(chuàng)建了一個(gè)新的person 對象：

var person = new Person({     'name': 'Phillip W' });

現(xiàn)在讓我們對新對象person 的屬性做一點(diǎn)修改。

person.set('name', 'Phillip W.');

上述代碼會(huì)對person 對象中的name 屬性進(jìn)行修改。接下來讓我們嘗試修改person 對象的address 屬性。在這之前，我們先對address屬性添加校驗(yàn)。

var Person = Backbone.Model.extend({     validate: function(attributes) {          if(isNaN(attributes.address.zipCode)) return "Address ZIP code must be a number!";     },      defaults: {         'name': 'John Doe',         'address': {             'street': '1st Street'             'city': 'Austin',             'state': 'TX'             'zipCode': 78701         }     }  });

現(xiàn)在，我們會(huì)嘗試使用一個(gè)不正確的ZIP 碼來修改對象的address 屬性。

var address = person.get('address'); address.zipCode = 'Hello World';// 應(yīng)該產(chǎn)生一個(gè)一個(gè)錯(cuò)誤因?yàn)閆IP碼是無效的 person.set('address', address); console.log(person.get('address')); /* 打印包含如下屬性的對象. {     'street': '1st Street'     'city': 'Austin',     'state': 'TX'     'zipCode': 'Hello World' } */

為什么會(huì)這樣？我們的校驗(yàn)方法不是已經(jīng)返回一個(gè)錯(cuò)誤了嗎？！為什么attributes 屬性還是被改變了？原因正如前面所說，Backbone.js不會(huì)復(fù)制模型的attributes對象； 它僅僅返回你所請求的東西。所以，你可能會(huì)猜到，如果你請求的是一個(gè)對象（如上面的address），你會(huì)得到那個(gè)對象的引用，并且你對這個(gè)對象的所有修 改都會(huì)直接地操作在模型中的實(shí)際對象中（因此這樣的修改方式并不會(huì)導(dǎo)致校驗(yàn)失敗，因?yàn)閷ο蟮囊貌]有改變）。這個(gè)問題很可能會(huì)導(dǎo)致你花費(fèi)幾小時(shí)來進(jìn)行調(diào) 試和診斷。

這個(gè)問題會(huì)逮住一些使用Backbone,js的新手甚至經(jīng)驗(yàn)豐富卻不夠警惕的JavaScript開發(fā)者。這個(gè)問題已經(jīng)在GitHub issues 的Backbone.js部分引起了大量的討論。像 Jeremy Ashkenas 所指出的，執(zhí)行深復(fù)制是一個(gè)非常棘手的問題，對那些有較大深度的對象來說，它將會(huì)是個(gè)非常昂貴的操作。

幸運(yùn)地，jQuery提供了一些深復(fù)制的實(shí)現(xiàn)，$.extend。順帶說一句，Underscore.js，Backbone.js的一個(gè)依賴插件，也提供了類似的方法 _.extend ，但我會(huì)避免使用它，因?yàn)樗⒉粓?zhí)行深復(fù)制。

var address = $.extend(true, {}, person.address);

我們現(xiàn)在得到了 address 對象的一個(gè)精確的拷貝，因此我們可以隨心所欲地修改它的內(nèi)容而不用擔(dān)心修改到person中的address  對象。你應(yīng)該意識(shí)到此模式適用于上述那個(gè)例子僅因?yàn)閍ddress 對象的所有成員都是原始值（numbers, strings,  等等），所以當(dāng)深復(fù)制的對象中還包含有子對象時(shí)必須謹(jǐn)慎地使用。你應(yīng)該知道執(zhí)行一個(gè)對象的深復(fù)制會(huì)產(chǎn)生一個(gè)小的性能影響，但我從沒見過它導(dǎo)致了什么顯而易 見的問題。盡管這樣，如果你對一個(gè)復(fù)雜對象的執(zhí)行深復(fù)制或者一次性執(zhí)行上千個(gè)對象的深復(fù)制，你可能會(huì)想做一些性能分析。這正是下一個(gè)模式出現(xiàn)的原因。

為對象創(chuàng)建Facades

在真實(shí)的世界里，需求經(jīng)常會(huì)更改，所以那些通過模型和集合的查詢而從終端返回的JSON數(shù)據(jù)也會(huì)有所改變。如果你的視圖與底層數(shù)據(jù)模型緊緊地耦合，這將會(huì)讓你感到非常麻煩。因此，我為所有的對象創(chuàng)建了獲取器和設(shè)置器。

很多人贊成這種模式。就是如果任何底層數(shù)據(jù)結(jié)構(gòu)被改變，視圖層不應(yīng)該更新太多；當(dāng)你只有一個(gè)數(shù)據(jù)入口的時(shí)候，你就不太可能忘記執(zhí)行深復(fù)制，并且你的代碼會(huì)變得更加可維護(hù)和調(diào)試。但帶來的負(fù)面影響是這種模式會(huì)讓你的模型和集合有點(diǎn)膨脹。

讓我們通過一個(gè)例子來搞清楚這個(gè)模式。假設(shè)我們有一個(gè)Hotel 模型，其中包含了rooms和當(dāng)前可用的rooms，我們希望能夠通過床位尺寸值來取得相應(yīng)的rooms。

var Hotel = Backbone.Model.extend({     defaults: {         "availableRooms": ["a"],         "rooms": {             "a": {                 "size": 1200,                 "bed": "queen"             },             "b": {                 "size": 900,                 "bed": "twin"             },             "c": {                 "size": 1100,                 "bed": "twin"             }         },          getRooms: function() {             $.extend(true, {}, this.get("rooms"));         },          getRoomsByBed: function(bed) {             return _.where(this.getRooms(), { "bed": bed });         }     } });

讓我們假設(shè)明天你將會(huì)發(fā)布你的代碼，并且終端的開發(fā)者忘記告訴你rooms的數(shù)據(jù)結(jié)構(gòu)從Object變成了一個(gè)array。你的代碼現(xiàn)在如下所示：

var Hotel = Backbone.Model.extend({     defaults: {         "availableRooms": ["a"],         "rooms": [             {                 "name": "a",                 "size": 1200,                 "bed": "queen"             },             {                 "name": "b",                 "size": 900,                 "bed": "twin"             },             {                 "name": "c",                 "size": 1100,                 "bed": "twin"             }         ],          getRooms: function() {             var rooms = $.extend(true, {}, this.get("rooms")),              newRooms = {};             // transform rooms from an array back into an object             _.each(rooms, function(room) {                 newRooms[room.name] = {                     "size": room.size,                     "bed": room.bed                 }             });         },          getRoomsByBed: function(bed) {             return _.where(this.getRooms(), { "bed": bed });         }     } });

為了將Hotel  轉(zhuǎn)換為應(yīng)用所期望的數(shù)據(jù)結(jié)構(gòu)，我們僅僅更新了一個(gè)方法，這讓我們整個(gè)App的仍然正常工作。如果我們沒有創(chuàng)建一個(gè)rooms數(shù)據(jù)的獲取器，我們可能不得不 更新每一個(gè)rooms的數(shù)據(jù)入口。理想情況下，你為了使用一個(gè)新的數(shù)據(jù)結(jié)構(gòu)而會(huì)想要更新所有的接口方法。但如果由于時(shí)間緊迫而不得不盡快發(fā)布代碼的話，這 個(gè)模式能拯救你。

順帶提一下，這個(gè)模式既可以被認(rèn)為是一個(gè)facade 設(shè)計(jì)模式，因?yàn)樗[藏了對象復(fù)制的細(xì)節(jié)，也可以被稱為 bridge 設(shè)計(jì)模式，因?yàn)樗梢员挥糜谵D(zhuǎn)換所期望的數(shù)據(jù)結(jié)構(gòu)。因而一個(gè)好的習(xí)慣是在所有的對象上使用獲取器和設(shè)置器。

存儲(chǔ)數(shù)據(jù)但不同步到服務(wù)器

盡管Backbone.js規(guī)定模型和集合會(huì)映射到REST-ful終端，但你有時(shí)候會(huì)發(fā)現(xiàn)你只是想將數(shù)據(jù)存儲(chǔ)在模型或者集合而不同步到服務(wù)器。一些其他關(guān)于Backbone.js的文章，像“Backbone.js Tips: Lessons From the Trenches”就講解過這個(gè)模式。讓我們快速地通過一個(gè)例子來看看什么時(shí)候這個(gè)模式會(huì)派上用場。假設(shè)你有個(gè)ul列表。

<ul>     <li><a href="#" data-id="1">One</a></li>     <li><a href="#" data-id="2">Two</a></li>     . . .     <li><a href="#" data-id="n">n</a></li> </ul>

當(dāng)n值為200并且用戶點(diǎn)擊了其中一個(gè)列表項(xiàng)，那個(gè)列表項(xiàng)會(huì)被選中并添加了一個(gè)類以直觀地顯示。實(shí)現(xiàn)它的一個(gè)方法如下所示：

var Model = Backbone.Model.extend({     defaults: {         items: [             {                 "name": "One",                 "id": 1                        },             {                 "name": "Two",                 "id": 2                        },             {                 "name": "Three",                 "id": 3                        }         ]     } });  var View = Backbone.View.extend({     template: _.template($('#list-template').html()),      events: {         "#items li a": "setSelectedItem"     },      render: function() {         $(this.el).html(this.template(this.model.toJSON()));     },      setSelectedItem: function(event) {         var selectedItem = $(event.currentTarget);        // Set all of the items to not have the selected class         $('#items li a').removeClass('selected');         selectedItem.addClass('selected');         return false;     } });  <script id="list-template" type="template">     <ul id="items">             <% for(i = items.length - 1; i >= 0; i--) { %>         <li>                     <a href="#" data-id="<%= item[i].id %>"><%= item[i].name %></a></li>     <% } %></ul> </script>

現(xiàn)在我們想要知道哪一個(gè)item被選中。一個(gè)方法是遍歷整個(gè)列表。但如果這個(gè)列表過長，這會(huì)是一個(gè)昂貴的操作。因此，當(dāng)用戶點(diǎn)擊其中的列表項(xiàng)時(shí)，我們應(yīng)該將它存儲(chǔ)起來。

var Model = Backbone.Model.extend({     defaults: {         selectedId: undefined,         items: [             {                 "name": "One",                 "id": 1             },             {                 "name": "Two",                 "id": 2             },             {                 "name": "Three",                 "id": 3             }         ]     } });  var View = Backbone.View.extend({     initialize: function(options) {        // Re-render when the model changes         this.model.on('change:items', this.render, this);     },      template: _.template($('#list-template').html()),      events: {         "#items li a": "setSelectedItem"     },      render: function() {         $(this.el).html(this.template(this.model.toJSON()));     },      setSelectedItem: function(event) {         var selectedItem = $(event.currentTarget);        // Set all of the items to not have the selected class         $('#items li a').removeClass('selected');         selectedItem.addClass('selected');        // Store a reference to what item was selected         this.model.set('selectedId', selectedItem.data('id'));         return false;     } });

現(xiàn)在我們能夠輕易地搜索我們的模型來確定哪一個(gè)item被選中，并且我們避免了遍歷文檔對象模型 (DOM)。這個(gè)模式對于存儲(chǔ)一些你想要跟蹤的外部數(shù)據(jù)非常有用；還要記住的是你能夠創(chuàng)建不需要與終端相關(guān)聯(lián)的模型和集合。

這個(gè)模式的消極影響是你的模型或集合并不是真正地采用RESTful 架構(gòu)因?yàn)樗鼈儧]有完美地映射到網(wǎng)絡(luò)資源。另外，這個(gè)模式會(huì)讓你的模型帶來一點(diǎn)兒膨脹；并且如果你的終端嚴(yán)格地只接收它所期望的JSON數(shù)據(jù)，它會(huì)給你帶來一點(diǎn)兒麻煩。

渲染視圖的一部分而不是渲染整個(gè)視圖

當(dāng)你第一次開發(fā)Backbone.js應(yīng)用，你的視圖一般會(huì)是這樣的結(jié)構(gòu)：

var View = Backbone.View.extend({     initialize: function(options) {         this.model.on('change', this.render, this);     },      template: _.template($(‘#template’).html()),      render: function() {         this.$el.html(template(this.model.toJSON());         $(‘#a’, this.$el).html(this.model.get(‘a’));         $(‘#b’, this.$el).html(this.model.get(‘b’));     } });

在這里，你的模型的任何改變都會(huì)觸發(fā)一次視圖的完整的重新渲染。當(dāng)我第一次使用Backbone.js來做開發(fā)的時(shí)候，我也使用過這種模式。但隨著我代碼的膨脹，我很快意識(shí)到這個(gè)方法是不可維護(hù)和不理想的，因?yàn)槟Ｐ偷娜魏螌傩缘母淖兌紩?huì)讓視圖完全重新渲染。

當(dāng)我遇到這個(gè)問題的時(shí)候，我馬上在Google搜索其他人是怎么做的并且找到了Ian Storm Taylor的博客寫的一篇文章, “Break Apart Your Backbone.js Render Methods,”，其中他提到了監(jiān)聽模型個(gè)別的屬性改變并且響應(yīng)的方法僅僅重新渲染視圖的一部分。Taylor也提到重渲染方法應(yīng)該返回自身的this對象，這樣那些單獨(dú)的重渲染方法就可以輕易地串聯(lián)起來。下面的這個(gè)例子已經(jīng)作出了修改而變得更易于維護(hù)和管理了，因?yàn)楫?dāng)模型屬性改變的時(shí)候我們僅僅更新相應(yīng)部分的視圖。

var View = Backbone.View.extend({     initialize: function(options) {         this.model.on('change:a', this.renderA, this);         this.model.on('change:b', this.renderB, this);     },      renderA: function() {         $(‘#a’, this.$el).html(this.model.get(‘a’));         return this;     },      renderB: function() {         $(‘#b’, this.$el).html(this.model.get(‘b’));         return this;     },      render: function() {         this             .renderA()             .renderB();     } });

還要提到的是，許多插件，像 Backbone.StickIt 和 Backbone.ModelBinder,提供了視圖元素和模型屬性之間的鍵值綁定，這能夠節(jié)省你很多的相似代碼。因此，如果你有很多復(fù)雜的表單字段，可以試著使用它們。

保持模型和視圖分離

像Jeremy Ashkenas 在Backbone.js的 GitHub issues指出的一個(gè)問題，除了模型不能夠由它們的視圖來創(chuàng)建以外，Backbone.js并不在數(shù)據(jù)層和視圖層之間實(shí)施任何真正的關(guān)注點(diǎn)分離。你覺得應(yīng)該在數(shù)據(jù)層和視圖層之間實(shí)施關(guān)注點(diǎn)分離嗎？我和其他的一些Backbone.js開發(fā)者，像Oz Katz和 Dayal，都認(rèn)為這個(gè)答案毫無疑問應(yīng)該是要的：模型和集合，代表著數(shù)據(jù)層，應(yīng)該禁止任何綁定到它們的視圖的入口，從而保持一個(gè)完全的關(guān)注點(diǎn)分離。如果你不遵循這個(gè)關(guān)注點(diǎn)分離，你的代碼很快就會(huì)變得像意大利面條那樣糾纏不清，而沒有人會(huì)喜歡這種代碼。

保持你的數(shù)據(jù)層和視圖層完全地分離可以使你擁有更加地模塊化，可重用和可維護(hù)的代碼。你能夠輕易地在你的應(yīng)用中重用和拓展模型和集合而不需要擔(dān)心和他們綁定的視圖。遵循這個(gè)模式能讓新加入項(xiàng)目的開發(fā)者快速的投入到代碼中。因?yàn)樗鼈兙_的知道哪里會(huì)發(fā)生視圖的渲染以及哪里存放著應(yīng)用的業(yè)務(wù)邏輯。

這個(gè)模式也強(qiáng)制使用了單一責(zé)任原則，該原則規(guī)定了每一個(gè)類應(yīng)該只有一個(gè)單獨(dú)的責(zé)任，并且它的職責(zé)應(yīng)該封裝在這個(gè)類中，因?yàn)槟愕哪Ｐ秃图蠎?yīng)該只負(fù)責(zé)處理數(shù)據(jù)，視圖應(yīng)該只負(fù)責(zé)處理渲染。

路由器中的參數(shù)映射

使用例子是展示這個(gè)模式如何產(chǎn)生的最好方法。例如：有一些搜索頁面，它們允許用戶添加兩個(gè)不同的過濾類型，foo 和bar，每一個(gè)都附有大量的選項(xiàng)。因此，你的URL結(jié)構(gòu)看起來將會(huì)像這樣：

'search/:foo' 'search/:bar' 'search/:foo/:bar'

現(xiàn)在，所有的路由使用一個(gè)確切的視圖和模型，所以，理想狀況下，你會(huì)樂意它們都用同一個(gè)方法，search()。但是，如果你檢查 Backbone.js，會(huì)發(fā)現(xiàn)沒有任何形式的參數(shù)映射；這些參數(shù)只是簡單地從左到右扔到方法里面去。所以，為了讓它們都能使用相同的方法，你最終要?jiǎng)?chuàng)建 不同的方法來正確地映射參數(shù)到search()方法。

routes: {     'search/:foo': 'searchFoo',     'search/:bar': 'searchBar',     'search/:foo/:bar': 'search' },  search: function(foo, bar) {     }, // I know this function will actually still map correctly, but for explanatory purposes, it's left in. searchFoo: function(foo) {     this.search(foo, undefined); },  searchBar: function(bar) {     this.search(undefined, bar); },

和你想的一樣，這種模式會(huì)快速地膨脹你的路由。當(dāng)我第一次使用接觸這種模式的時(shí)候，我嘗試使用正則表達(dá)式在實(shí)際方法定義中做一些解析而“神奇地”映 射這些參數(shù)，但這只能在參數(shù)容易區(qū)分的情況下起作用。所以我放棄了這個(gè)方法（我有時(shí)候依然會(huì)在Backbone插件中使用它）。我在issue on GitHub上提出過這個(gè)問題，Ashkenas 給我的建議是在search方法中映射所有的參數(shù)。

下面這段代碼已經(jīng)變得更加具備可維護(hù)性：

routes: {     'base/:foo': 'search',     'base/:bar': 'search',     'base/:foo/:bar': 'search' },  search: function() {     var foo, bar, i;      for(i = arguments.length - 1; i >= 0; i--) {          if(arguments[i] === 'something to determine foo') {             foo = arguments[i];             continue;         }         else if(arguments[i] === 'something to determine bar') {             bar = arguments[i];             continue;         }     } },

這個(gè)模式可以徹底地減少路由器的膨脹。然而，要意識(shí)到它對于不可識(shí)別的參數(shù)時(shí)無效的。舉個(gè)例子，如果你有兩個(gè)傳遞ID的參數(shù)并且都它們以 XXXX-XXXX 這種模式表現(xiàn)，你將無法確定哪一個(gè)ID對應(yīng)的是哪一個(gè)參數(shù)。

model.fetch() 不會(huì)清除你的模型

這個(gè)問題通常會(huì)絆倒使用Backbone.js的新手： model.fetch() 并不會(huì)清理你的模型，而是會(huì)將取回來的數(shù)據(jù)合并到你的模型當(dāng)中。因此，如果你當(dāng)前的模型有x,，y 和 z 屬性并且你通過fetch得到了一個(gè)新的 y 和z 值，接下來 x 會(huì)保持模型原來的值，僅僅 y 和z 的值會(huì)得到更新，下面這個(gè)例子直觀地說明了這個(gè)概念。

var Model = Backbone.Model.extend({     defaults: {         x: 1,         y: 1,         z: 1     } }); var model = new Model(); /* model.attributes yields {     x: 1,     y: 1,     z: 1 } */ model.fetch(); /* let’s assume that the endpoint returns this {     y: 2,     z: 2, } */ /* model.attributes now yields {     x: 1,     y: 2,     z: 2 } */

PUT請求需要一個(gè)ID屬性

這個(gè)問題也只通常出現(xiàn)在Backbone.js的新手中。當(dāng)你調(diào)用.save() 方法時(shí)，你會(huì)發(fā)送一個(gè)HTTP PUT  請求，要求你的模型已經(jīng)設(shè)置了一個(gè)ID屬性。HTTP PUT  是被設(shè)計(jì)為一個(gè)更新動(dòng)作的，所以發(fā)送PUT請求的時(shí)候要求你的模型已有一個(gè)ID屬性是合情理的。在理想的世界里，你的所有模型都會(huì)有一個(gè)名為id的屬性， 但現(xiàn)實(shí)情況是，你從終端接收的JSON數(shù)據(jù)的ID屬性并不總是會(huì)剛好命名為id。

因此，如果你需要更新你的模型，請確定在保存前你的模型具有一個(gè)ID。當(dāng)終端返回的ID屬性變量名不為 id 的時(shí)候，0.5及以上的版本的Backbone.js允許你使用 idAttribute 來改變ID屬性的名字。

如果使用的Backbone.js的版本仍低于0.5，我建議你修改集合或模型中的 parse 方法來映射期望的ID屬性到真正的ID屬性。這里有一個(gè)讓你快速掌握這個(gè)技巧的例子，讓我們假設(shè)你有一個(gè)cars集合，它的ID屬性名為carID .

parse: function(response) {      _.each(response.cars, function(car, i) {        // map the returned ID of carID to the correct attribute ID         response.cars[i].id = response.cars[i].carID;     });      return response; },

頁面加載中的模型數(shù)據(jù)

一些時(shí)候你會(huì)發(fā)現(xiàn)你需要在頁面加載的時(shí)候就使用數(shù)據(jù)來初始化你的集合和模型。一些關(guān)于Backbone.js模式的文章，像Rico Sta Cruz的“Backbone Patterns”和Katz的“Avoiding Common Backbone.js Pitfalls,”談?wù)摰搅诉@個(gè)模式。使用你選擇的服務(wù)端語言，通過嵌入代碼到頁面并將數(shù)據(jù)放在單個(gè)模型的屬性或JSON當(dāng)中，你能夠輕易地實(shí)現(xiàn)這個(gè)模式。舉個(gè)例子，在Rails中，我會(huì)這樣使用：

// a single attribute var model = new Model({     hello: <%= @world %> });// or to have json var model = new Model(<%= @hello_world.to_json %>);

使用這個(gè)模式能夠通過“馬上渲染你的頁面”來提高你的搜索引擎排名，并且它能通過限制應(yīng)用的HTTP請求來徹底地縮短你的應(yīng)用啟動(dòng)和運(yùn)行所花費(fèi)的時(shí)間。

處理驗(yàn)證失敗的模型屬性

你經(jīng)常會(huì)想知道哪一個(gè)模型屬性的驗(yàn)證失敗了。舉個(gè)例子，如果你有一個(gè)極度復(fù)雜的表單域，你可能想知道哪一個(gè)模型屬性驗(yàn)證失敗，這樣你能夠高亮顯示相 應(yīng)的表單域。不幸的是，提醒你的視圖哪一個(gè)模型屬性驗(yàn)證失敗并沒有直接在Backbone.js中實(shí)現(xiàn)，但你可以使用不同的模式來處理這個(gè)問題。

返回一個(gè)錯(cuò)誤對象

通知你的視圖哪一個(gè)模型屬性驗(yàn)證失敗的一個(gè)模式是回傳一個(gè)帶有某種標(biāo)志的對象，該對象中詳述哪一個(gè)模型屬性驗(yàn)證失敗，就像下面這樣：

// Inside your model validate: function(attrs) {     var errors = [];      if(attrs.a < 0) {         errors.push({             'message': 'Form field a is messed up!',             'class': 'a'         });     }     if(attrs.b < 0) {         errors.push({             'message': 'Form field b is messed up!',             'class': 'b'         });     }      if(errors.length) {         return errors;     } }// Inside your view this.model.on('invalid&rsquo;, function(model, errors) {     _.each(errors, function(error, i) {         $(&lsquo;.&rsquo; + error.class).addClass('error');         alert(error.message);     }); });

這個(gè)模式的優(yōu)點(diǎn)是你在一個(gè)位置處理了所有的無效信息。缺點(diǎn)是如果你處理不同的無效屬性，你的屬性校驗(yàn)部分會(huì)變?yōu)橐粋€(gè)比較大的 switch 或 if 語句。

廣播傳統(tǒng)錯(cuò)誤事件

由我朋友Derick Bailey建議的一個(gè)替換的模式，是對個(gè)別的模型屬性觸發(fā)自定義錯(cuò)誤事件。這能讓你的視圖為個(gè)別的屬性綁定指定的錯(cuò)誤事件。

// Inside your model validate: function(attrs) {      if(attrs.a < 0) {             this.trigger(&lsquo;invalid:a&rsquo;, 'Form field a is messed up!', this);     }     if(attrs.b < 0) {             this.trigger(&lsquo;invalid:b&rsquo;, 'Form field b is messed up!', this);     } }// Inside your view this.model.on('invalid:a&rsquo;, function(error) {         $(&lsquo;a&rsquo;).addClass('error');         alert(error); }); this.model.on('invalid:b&rsquo;, function(error) {         $(&lsquo;b&rsquo;).addClass('error');         alert(error); });

這個(gè)模式的優(yōu)點(diǎn)是你的視圖綁定了明確類型的錯(cuò)誤事件，并且如果你對每一類型的屬性錯(cuò)誤有明確的執(zhí)行指令，它能整頓你視圖代碼并使它更加可維護(hù)。這個(gè)模式的一個(gè)缺點(diǎn)是如果存在太多不同的想要處理的屬性錯(cuò)誤，你的視圖代碼會(huì)變得更加臃腫。

兩個(gè)模式都有他們的優(yōu)缺點(diǎn)，所以在你應(yīng)該考慮哪一種模式更加適合你的用例。如果你想對所有的驗(yàn)證失敗處理都采用一個(gè)方法，那第一個(gè)方法會(huì)是個(gè)好選擇；如果你的每一個(gè)模型屬性都有明確的UI改變，那選第二個(gè)方法會(huì)更好。

HTTP狀態(tài)碼200觸發(fā)錯(cuò)誤

如果你的模型或集合訪問的終端返回了無效的JSON數(shù)據(jù)，它們會(huì)觸發(fā)一個(gè)“error”事件，即使你的終端返回的HTTP狀態(tài)碼是200。這個(gè)情況通常出現(xiàn)在根據(jù)模擬JSON數(shù)據(jù)來做本地開發(fā)的時(shí)候。所以一個(gè)好方法是把你正在開發(fā)中的所有的模擬JSON文件都扔到JSON 驗(yàn)證器中檢驗(yàn)?；蛘邽槟愕腎DE安裝一個(gè)插件可以捕捉任何格式錯(cuò)誤的JSON。

創(chuàng)建一個(gè)通用的錯(cuò)誤展示

創(chuàng)建一個(gè)通用的錯(cuò)誤展示意味著你有一個(gè)統(tǒng)一的模式來處理和顯示錯(cuò)誤信息，這能夠節(jié)省你的時(shí)間，并能提升用戶的整體體驗(yàn)。在我開發(fā)的任何的Backbone.js 應(yīng)用中我都創(chuàng)建了一個(gè)通用的視圖來處理警告。

var AlertView = Backbone.View.extend({     set: function(typeOfError, message) {         var alert = $(‘.in-page-alert’).length ? $(‘.in-page-alert’): $(‘.body-alert’);         alert             .removeClass(‘error success warning’)             .html(message)             .fadeIn()             .delay(5000)             .fadeOut();     } });

上面這個(gè)視圖首先查看在視圖之內(nèi)是否已經(jīng)聲明了 in-page-alert div。如果沒有聲明，它會(huì)回到被聲明在布局的某個(gè)地方的通用  body-alert div中。這讓你能夠傳遞一個(gè)一致的錯(cuò)誤信息給你用戶，并在你忘記指定一個(gè)特定的 in-page-alert  div時(shí)提供有效的備用div。上面的模式簡化了你在視圖中對錯(cuò)誤信息的處理工作，如下面所示：

this.model.on('error', function(model, error) {     alert.set('TYPE-OF-ERROR', error); });

更新單頁應(yīng)用的文檔標(biāo)題

這比關(guān)注任何東西都更加有用。如果你正在開發(fā)一個(gè)單頁應(yīng)用，請記得更新每一頁的文檔標(biāo)題！我寫過一個(gè)簡單的Backbone.js插件，Backbone.js Router Title Helper，它通過拓展Backbone.js路由器來簡單又優(yōu)雅地實(shí)現(xiàn)這個(gè)功能。它允許你指定一個(gè)標(biāo)題的對象常量，它的鍵映射到路由的方法名，值則是頁標(biāo)題。

Backbone.Router = Backbone.Router.extend({      initialize: function(options){         var that = this;          this.on('route', function(router, route, params) {              if(that.titles) {                 if(that.titles[router]) document.title = that.titles[router];                 else if(that.titles.default) document.title = that.titles.default;                 else throw 'Backbone.js Router Title Helper: No title found for route:' + router + ' and no default route specified.';             }         });     } });

在單頁應(yīng)用中緩存對象

當(dāng)我們討論單頁應(yīng)用的時(shí)候，你有必要遵循的另一個(gè)模式是緩存那些將會(huì)被重復(fù)使用的對象。這個(gè)技巧是相當(dāng)簡單和直接的：

// Inside a router initialize: function() {      this.cached = {         view: undefined,         model: undefined     } },  index: function(parameter) {     this.cached.model = this.cached.model || new Model({         parameter: parameter     });     this.cached.view = this.cached.view || new View({         model: this.cached.model     }); }

這個(gè)模式將會(huì)讓你的應(yīng)用像小石子那般飛快起來，因?yàn)槟悴恍枰匦鲁跏蓟愕腂ackbone.js對象。然而，它可能會(huì)導(dǎo)致你的應(yīng)用的內(nèi)存占用變得相當(dāng)大；因此，我一般僅僅緩存那些貫穿整個(gè)應(yīng)用的對象。如果你以前開發(fā)過Backbone.js應(yīng)用，你可能會(huì)問自己“如果我想重新獲取數(shù)據(jù)會(huì)怎樣？”那么你可以在每次路由被觸發(fā)的時(shí)候重新獲取數(shù)據(jù)。

// Inside a router initialize: function() {      this.cached = {         view: undefined,         model: undefined     } },  index: function(parameter) {     this.cached.model = this.cached.model || new Model({         parameter: parameter     });     this.cached.view = this.cached.view || new View({         model: this.cached.model     });     this.cached.model.fetch(); }

當(dāng)你的應(yīng)用必須從終端中取回最新數(shù)據(jù)的時(shí)候（例如，一個(gè)收信箱），這個(gè)模式會(huì)很好用。然而，如果你正在取回的數(shù)據(jù)依賴應(yīng)用的狀態(tài)（假設(shè)狀態(tài)是靠你的URL 和參數(shù)維持的），那即使自用戶上一次瀏覽頁面以來應(yīng)用的狀態(tài)沒有改變，你仍會(huì)更新數(shù)據(jù)。一個(gè)比較好的解決辦法是僅當(dāng)應(yīng)用的狀態(tài)（parameter）被改 變的時(shí)候才更新數(shù)據(jù)。

// Inside a router initialize: function() {      this.cached = {         view: undefined,         model: undefined     } },  index: function(parameter) {     this.cached.model = this.cached.model || new Model({         parameter:parameter     });     this.cached.model.set('parameter', parameter);     this.cached.view = this.cached.view || new View({         model: this.cached.model     }); } // Inside of the model initialize: function() {     this.on("change:parameter", this.fetchData, this); }

JSDoc功能和Backbone.js的類

我喜歡編制文檔并且是JSDoc的忠實(shí)粉絲，我用JSDoc 為所有遵循下面所示格式的Backbone 類和方法生成了文檔：

var Thing = Backbone.View.extend(/** @lends Thing.prototype */{     /** @class Thing      * @author Phillip Whisenhunt      * @augments Backbone.View      * @contructs Thing object */     initialize() {},      /** Gets data by ID from the thing. If the thing doesn't have data based on the ID, an empty string is returned.      * @param {String} id The id of get data for.      * @return {String} The data. */     getDataById: function(id) {} });

如果你為上面這種格式的Backbone類編制文檔，你可以編制一份漂亮的文檔，它包含你所有的類和帶有參數(shù)，返回值和描述的方法。請確保initialize 始終是第一個(gè)聲明的方法，因?yàn)檫@有助于生成JSDoc。如果你想要看一個(gè)使用JSDoc的項(xiàng)目的例子，請查閱HomeAway Calendar Widget。有個(gè) Grunt.js 插件，grunt-jsdoc-plugin 插件，使用它們會(huì)把生成文檔作為構(gòu)建過程的一部分。

實(shí)踐測試驅(qū)動(dòng)開發(fā)

在我看來，如果你正在使用Backbone.js，你應(yīng)該讓你模型和集合遵循測試驅(qū)動(dòng)開發(fā)(TDD)。我通過第一次為我的模型和集合編寫失敗的 Jasmine.js  單元測試而開始遵循TDD。一旦我寫的單元測試編寫和失敗，我就把模型和集合排出。通過這一點(diǎn)，我所有的Jasmine  測試將會(huì)被傳遞，并且我有信心我的模型方法全部都會(huì)像預(yù)期般工作。因?yàn)槲乙恢弊裱璗DD，我的視圖層已經(jīng)可以相當(dāng)容易地編寫并會(huì)極度地輕薄。當(dāng)你剛開始實(shí) 踐TDD的時(shí)候，你肯定會(huì)慢下來；不過一旦你深入其中，你的生產(chǎn)力和代碼質(zhì)量都會(huì)大大提升。

關(guān)于如何理解Backbone.js 的技巧和模式就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

分享標(biāo)題：如何理解Backbone.js的技巧和模式
標(biāo)題路徑：http://www.rwnh.cn/article32/ippgpc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、網(wǎng)站設(shè)計(jì)、云服務(wù)器、服務(wù)器托管、品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)