Backbone.js是一個開源JavaScript“MV*”框架， 在三年前它的第一次發(fā)布的時候就獲得了顯著的推動。盡管Backbone.js為Javascript應用程序提供了自己的結構，但它留下了大量根據開發(fā) 者的需要而使用的設計模式和決策，并且當開發(fā)者們第一次使用Backbone.js開發(fā)的時候都會遇到許多共同的問題。
讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：域名注冊、網頁空間、營銷軟件、網站建設、成都網站維護、網站推廣。
因此，在這篇文章中，我們除了會探索各種各樣你能夠應用到你的Backbone.js應用中的設計模式外，我們也會關注一些困惑開發(fā)者的常見問題。
執(zhí)行對象的深復制
JavaScript中所有原始類型變量的傳遞都是值傳遞。所以，當變量被引用的時候會傳遞該變量的值。
- var helloWorld = “Hello World”;
- var helloWorldCopy = helloWorld;
例如，以上代碼會將helloWorldCopy 的值設為helloWorld的值。所以對于helloWorldCopy 的所有修改都不會改變helloWorld, 因為它是一個拷貝。另一方面，JavaScript所有非原始類型變量的傳遞都是引用傳遞，意思是當變量被引用的時候，JavaScript會傳遞一個其內存地址的參照。
- var helloWorld = {
- ‘hello’: ‘world’
- }
- var helloWorldCopy = helloWorld;
舉個例子，上面的代碼會將helloWorldCopy 設為helloWorld 對象的別名，此時，你可能會猜到，對helloWorldCopy 的所有修改都會直接在helloWorld 對象上進行。如果你想得到一個helloWorld 對象的拷貝，你必須對這個對象進行一次復制。
你可能想知道，“為什么他（作者）要在這篇文章中解釋這些按引用傳遞的東西？”很好，這是因為在Backbone.js的對象傳遞中，并不對進行對象復制，意味著如果你在一個模型中調用 get( ) 方法來取得一個對象，那么對它的任何修改都會直接在模型中的那個對象進行操作！讓我們通過一個例子來看看什么時候它會成為你的麻煩。假設現在你有一個如下的Person 模型：
- var Person = Backbone.Model.extend({
- defaults: {
- 'name': 'John Doe',
- 'address': {
- 'street': '1st Street'
- 'city': 'Austin',
- 'state': 'TX'
- 'zipCode': 78701
- }
- }
- });
并且假設你創(chuàng)建了一個新的person 對象：
- var person = new Person({
- 'name': 'Phillip W'
- });
現在讓我們對新對象person 的屬性做一點修改。
- person.set('name', 'Phillip W.');
上述代碼會對person 對象中的name 屬性進行修改。接下來讓我們嘗試修改person 對象的address 屬性。在這之前，我們先對address屬性添加校驗。
- 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
- }
- }
- });
現在，我們會嘗試使用一個不正確的ZIP 碼來修改對象的address 屬性。
- var address = person.get('address');
- address.zipCode = 'Hello World';// 應該產生一個一個錯誤因為ZIP碼是無效的
- person.set('address', address);
- console.log(person.get('address'));
- /* 打印包含如下屬性的對象.
- {
- 'street': '1st Street'
- 'city': 'Austin',
- 'state': 'TX'
- 'zipCode': 'Hello World'
- }
- */
為什么會這樣？我們的校驗方法不是已經返回一個錯誤了嗎？！為什么attributes 屬性還是被改變了？原因正如前面所說，Backbone.js不會復制模型的attributes對象； 它僅僅返回你所請求的東西。所以，你可能會猜到，如果你請求的是一個對象（如上面的address），你會得到那個對象的引用，并且你對這個對象的所有修 改都會直接地操作在模型中的實際對象中（因此這樣的修改方式并不會導致校驗失敗，因為對象的引用并沒有改變）。這個問題很可能會導致你花費幾小時來進行調 試和診斷。
這個問題會逮住一些使用Backbone,js的新手甚至經驗豐富卻不夠警惕的JavaScript開發(fā)者。這個問題已經在GitHub issues 的Backbone.js部分引起了大量的討論。像 Jeremy Ashkenas 所指出的，執(zhí)行深復制是一個非常棘手的問題，對那些有較大深度的對象來說，它將會是個非常昂貴的操作。
幸運地，jQuery提供了一些深復制的實現，$.extend。順帶說一句，Underscore.js，Backbone.js的一個依賴插件，也提供了類似的方法 _.extend ，但我會避免使用它，因為它并不執(zhí)行深復制。
- var address = $.extend(true, {}, person.address);
我們現在得到了 address 對象的一個精確的拷貝，因此我們可以隨心所欲地修改它的內容而不用擔心修改到person中的address 對象。你應該意識到此模式適用于上述那個例子僅因為address 對象的所有成員都是原始值（numbers, strings, 等等），所以當深復制的對象中還包含有子對象時必須謹慎地使用。你應該知道執(zhí)行一個對象的深復制會產生一個小的性能影響，但我從沒見過它導致了什么顯而易 見的問題。盡管這樣，如果你對一個復雜對象的執(zhí)行深復制或者一次性執(zhí)行上千個對象的深復制，你可能會想做一些性能分析。這正是下一個模式出現的原因。
#p#
為對象創(chuàng)建Facades
在真實的世界里，需求經常會更改，所以那些通過模型和集合的查詢而從終端返回的JSON數據也會有所改變。如果你的視圖與底層數據模型緊緊地耦合，這將會讓你感到非常麻煩。因此，我為所有的對象創(chuàng)建了獲取器和設置器。
很多人贊成這種模式。就是如果任何底層數據結構被改變，視圖層不應該更新太多；當你只有一個數據入口的時候，你就不太可能忘記執(zhí)行深復制，并且你的代碼會變得更加可維護和調試。但帶來的負面影響是這種模式會讓你的模型和集合有點膨脹。
讓我們通過一個例子來搞清楚這個模式。假設我們有一個Hotel 模型，其中包含了rooms和當前可用的rooms，我們希望能夠通過床位尺寸值來取得相應的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 });
- }
- }
- });
讓我們假設明天你將會發(fā)布你的代碼，并且終端的開發(fā)者忘記告訴你rooms的數據結構從Object變成了一個array。你的代碼現在如下所示：
- 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 轉換為應用所期望的數據結構，我們僅僅更新了一個方法，這讓我們整個App的仍然正常工作。如果我們沒有創(chuàng)建一個rooms數據的獲取器，我們可能不得不 更新每一個rooms的數據入口。理想情況下，你為了使用一個新的數據結構而會想要更新所有的接口方法。但如果由于時間緊迫而不得不盡快發(fā)布代碼的話，這 個模式能拯救你。
順帶提一下，這個模式既可以被認為是一個facade 設計模式，因為它隱藏了對象復制的細節(jié)，也可以被稱為 bridge 設計模式，因為它可以被用于轉換所期望的數據結構。因而一個好的習慣是在所有的對象上使用獲取器和設置器。
存儲數據但不同步到服務器
盡管Backbone.js規(guī)定模型和集合會映射到REST-ful終端，但你有時候會發(fā)現你只是想將數據存儲在模型或者集合而不同步到服務器。一些其他關于Backbone.js的文章，像“Backbone.js Tips: Lessons From the Trenches”就講解過這個模式。讓我們快速地通過一個例子來看看什么時候這個模式會派上用場。假設你有個ul列表。
-
- One
-
- Two
- . . .
-
- n
-
當n值為200并且用戶點擊了其中一個列表項，那個列表項會被選中并添加了一個類以直觀地顯示。實現它的一個方法如下所示：
- 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;
- }
- });
-
-
-
- <% for(i = items.length - 1; i >= 0; i--) { %>
-
-
- "><%= item[i].name %>
- <% } %>
-
現在我們想要知道哪一個item被選中。一個方法是遍歷整個列表。但如果這個列表過長，這會是一個昂貴的操作。因此，當用戶點擊其中的列表項時，我們應該將它存儲起來。
- 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;
- }
- });
現在我們能夠輕易地搜索我們的模型來確定哪一個item被選中，并且我們避免了遍歷文檔對象模型 (DOM)。這個模式對于存儲一些你想要跟蹤的外部數據非常有用；還要記住的是你能夠創(chuàng)建不需要與終端相關聯(lián)的模型和集合。
這個模式的消極影響是你的模型或集合并不是真正地采用RESTful 架構因為它們沒有完美地映射到網絡資源。另外，這個模式會讓你的模型帶來一點兒膨脹；并且如果你的終端嚴格地只接收它所期望的JSON數據，它會給你帶來一點兒麻煩。
#p#
渲染視圖的一部分而不是渲染整個視圖
當你第一次開發(fā)Backbone.js應用，你的視圖一般會是這樣的結構：
- 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’));
- }
- });
在這里，你的模型的任何改變都會觸發(fā)一次視圖的完整的重新渲染。當我第一次使用Backbone.js來做開發(fā)的時候，我也使用過這種模式。但隨著我代碼的膨脹，我很快意識到這個方法是不可維護和不理想的，因為模型的任何屬性的改變都會讓視圖完全重新渲染。
當我遇到這個問題的時候，我馬上在Google搜索其他人是怎么做的并且找到了Ian Storm Taylor的博客寫的一篇文章, “Break Apart Your Backbone.js Render Methods,”，其中他提到了監(jiān)聽模型個別的屬性改變并且響應的方法僅僅重新渲染視圖的一部分。Taylor也提到重渲染方法應該返回自身的this對象，這樣那些單獨的重渲染方法就可以輕易地串聯(lián)起來。下面的這個例子已經作出了修改而變得更易于維護和管理了，因為當模型屬性改變的時候我們僅僅更新相應部分的視圖。
- 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é)省你很多的相似代碼。因此，如果你有很多復雜的表單字段，可以試著使用它們。
保持模型和視圖分離
像Jeremy Ashkenas 在Backbone.js的 GitHub issues指出的一個問題，除了模型不能夠由它們的視圖來創(chuàng)建以外，Backbone.js并不在數據層和視圖層之間實施任何真正的關注點分離。你覺得應該在數據層和視圖層之間實施關注點分離嗎？我和其他的一些Backbone.js開發(fā)者，像Oz Katz和 Dayal，都認為這個答案毫無疑問應該是要的：模型和集合，代表著數據層，應該禁止任何綁定到它們的視圖的入口，從而保持一個完全的關注點分離。如果你不遵循這個關注點分離，你的代碼很快就會變得像意大利面條那樣糾纏不清，而沒有人會喜歡這種代碼。
保持你的數據層和視圖層完全地分離可以使你擁有更加地模塊化，可重用和可維護的代碼。你能夠輕易地在你的應用中重用和拓展模型和集合而不需要擔心和他們綁定的視圖。遵循這個模式能讓新加入項目的開發(fā)者快速的投入到代碼中。因為它們精確的知道哪里會發(fā)生視圖的渲染以及哪里存放著應用的業(yè)務邏輯。
這個模式也強制使用了單一責任原則，該原則規(guī)定了每一個類應該只有一個單獨的責任，并且它的職責應該封裝在這個類中，因為你的模型和集合應該只負責處理數據，視圖應該只負責處理渲染。
路由器中的參數映射
使用例子是展示這個模式如何產生的最好方法。例如：有一些搜索頁面，它們允許用戶添加兩個不同的過濾類型，foo 和bar，每一個都附有大量的選項。因此，你的URL結構看起來將會像這樣：
- 'search/:foo'
- 'search/:bar'
- 'search/:foo/:bar'
現在，所有的路由使用一個確切的視圖和模型，所以，理想狀況下，你會樂意它們都用同一個方法，search()。但是，如果你檢查 Backbone.js，會發(fā)現沒有任何形式的參數映射；這些參數只是簡單地從左到右扔到方法里面去。所以，為了讓它們都能使用相同的方法，你最終要創(chuàng)建 不同的方法來正確地映射參數到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);
- },
和你想的一樣，這種模式會快速地膨脹你的路由。當我第一次使用接觸這種模式的時候，我嘗試使用正則表達式在實際方法定義中做一些解析而“神奇地”映 射這些參數，但這只能在參數容易區(qū)分的情況下起作用。所以我放棄了這個方法（我有時候依然會在Backbone插件中使用它）。我在issue on GitHub上提出過這個問題，Ashkenas 給我的建議是在search方法中映射所有的參數。
下面這段代碼已經變得更加具備可維護性：
- 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;
- }
- }
- },
這個模式可以徹底地減少路由器的膨脹。然而，要意識到它對于不可識別的參數時無效的。舉個例子，如果你有兩個傳遞ID的參數并且都它們以 XXXX-XXXX 這種模式表現，你將無法確定哪一個ID對應的是哪一個參數。
model.fetch() 不會清除你的模型
這個問題通常會絆倒使用Backbone.js的新手： model.fetch() 并不會清理你的模型，而是會將取回來的數據合并到你的模型當中。因此，如果你當前的模型有x,，y 和 z 屬性并且你通過fetch得到了一個新的 y 和z 值，接下來 x 會保持模型原來的值，僅僅 y 和z 的值會得到更新，下面這個例子直觀地說明了這個概念。
- 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
- } */
#p#
PUT請求需要一個ID屬性
這個問題也只通常出現在Backbone.js的新手中。當你調用.save() 方法時，你會發(fā)送一個HTTP PUT 請求，要求你的模型已經設置了一個ID屬性。HTTP PUT 是被設計為一個更新動作的，所以發(fā)送PUT請求的時候要求你的模型已有一個ID屬性是合情理的。在理想的世界里，你的所有模型都會有一個名為id的屬性， 但現實情況是，你從終端接收的JSON數據的ID屬性并不總是會剛好命名為id。
因此，如果你需要更新你的模型，請確定在保存前你的模型具有一個ID。當終端返回的ID屬性變量名不為 id 的時候，0.5及以上的版本的Backbone.js允許你使用 idAttribute 來改變ID屬性的名字。
如果使用的Backbone.js的版本仍低于0.5，我建議你修改集合或模型中的 parse 方法來映射期望的ID屬性到真正的ID屬性。這里有一個讓你快速掌握這個技巧的例子，讓我們假設你有一個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;
- },
頁面加載中的模型數據
一些時候你會發(fā)現你需要在頁面加載的時候就使用數據來初始化你的集合和模型。一些關于Backbone.js模式的文章，像Rico Sta Cruz的“Backbone Patterns”和Katz的“Avoiding Common Backbone.js Pitfalls,”談論到了這個模式。使用你選擇的服務端語言，通過嵌入代碼到頁面并將數據放在單個模型的屬性或JSON當中，你能夠輕易地實現這個模式。舉個例子，在Rails中，我會這樣使用：
- // a single attribute
- var model = new Model({
- hello: <%= @world %>
- });// or to have json
- var model = new Model(<%= @hello_world.to_json %>);
使用這個模式能夠通過“馬上渲染你的頁面”來提高你的搜索引擎排名，并且它能通過限制應用的HTTP請求來徹底地縮短你的應用啟動和運行所花費的時間。
處理驗證失敗的模型屬性
你經常會想知道哪一個模型屬性的驗證失敗了。舉個例子，如果你有一個極度復雜的表單域，你可能想知道哪一個模型屬性驗證失敗，這樣你能夠高亮顯示相 應的表單域。不幸的是，提醒你的視圖哪一個模型屬性驗證失敗并沒有直接在Backbone.js中實現，但你可以使用不同的模式來處理這個問題。
返回一個錯誤對象
通知你的視圖哪一個模型屬性驗證失敗的一個模式是回傳一個帶有某種標志的對象，該對象中詳述哪一個模型屬性驗證失敗，就像下面這樣：
- // 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’, function(model, errors) {
- _.each(errors, function(error, i) {
- $(‘.’ + error.class).addClass('error');
- alert(error.message);
- });
- });
這個模式的優(yōu)點是你在一個位置處理了所有的無效信息。缺點是如果你處理不同的無效屬性，你的屬性校驗部分會變?yōu)橐粋€比較大的 switch 或 if 語句。
廣播傳統(tǒng)錯誤事件
由我朋友Derick Bailey建議的一個替換的模式，是對個別的模型屬性觸發(fā)自定義錯誤事件。這能讓你的視圖為個別的屬性綁定指定的錯誤事件。
- // Inside your model
- validate: function(attrs) {
-
- if(attrs.a < 0) {
- this.trigger(‘invalid:a’, 'Form field a is messed up!', this);
- }
- if(attrs.b < 0) {
- this.trigger(‘invalid:b’, 'Form field b is messed up!', this);
- }
- }// Inside your view
- this.model.on('invalid:a’, function(error) {
- $(‘a’).addClass('error');
- alert(error);
- });
- this.model.on('invalid:b’, function(error) {
- $(‘b’).addClass('error');
- alert(error);
- });
這個模式的優(yōu)點是你的視圖綁定了明確類型的錯誤事件，并且如果你對每一類型的屬性錯誤有明確的執(zhí)行指令，它能整頓你視圖代碼并使它更加可維護。這個模式的一個缺點是如果存在太多不同的想要處理的屬性錯誤，你的視圖代碼會變得更加臃腫。
兩個模式都有他們的優(yōu)缺點，所以在你應該考慮哪一種模式更加適合你的用例。如果你想對所有的驗證失敗處理都采用一個方法，那第一個方法會是個好選擇；如果你的每一個模型屬性都有明確的UI改變，那選第二個方法會更好。
HTTP狀態(tài)碼200觸發(fā)錯誤
如果你的模型或集合訪問的終端返回了無效的JSON數據，它們會觸發(fā)一個“error”事件，即使你的終端返回的HTTP狀態(tài)碼是200。這個情況通常出現在根據模擬JSON數據來做本地開發(fā)的時候。所以一個好方法是把你正在開發(fā)中的所有的模擬JSON文件都扔到JSON 驗證器中檢驗?；蛘邽槟愕腎DE安裝一個插件可以捕捉任何格式錯誤的JSON。
創(chuàng)建一個通用的錯誤展示
創(chuàng)建一個通用的錯誤展示意味著你有一個統(tǒng)一的模式來處理和顯示錯誤信息，這能夠節(jié)省你的時間，并能提升用戶的整體體驗。在我開發(fā)的任何的Backbone.js 應用中我都創(chuàng)建了一個通用的視圖來處理警告。
- 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)
- &n
分享名稱：Backbone.js的技巧和模式
網站路徑：http://uogjgqi.cn/article/cdojesi.html
