Question

我创建了一个简单的骨干项目，它可以获取所有书籍详细信息并在UI中显示。我正在从模型中获取所有书籍细节。完全没有使用像这样的集合

var BookModel= Backbone.Model.extend({
    initialize: function(){
       this.fetchData();
    },

    fetchData: function(){
        this.url= "/get/all_books";

        this.fetch({
            success: success_callback,
            error: error_callback
        })
    }
});

这很好用。但为什么我必须使用收藏品？如果我会使用收集，它将如下所示

var BookModel= Backbone.Model.extend({
    defaults:{
        id:'',
        name: '',
        author: ''
    }
});


var BookCollection= Backbone.Collection.extend({
    model: BookModel,

    initialize: function(){
        this.fetchData();
    },

    fetchData: function(){
        this.url= "/get/all_books";

        this.fetch({
            success: success_callback,
            error: error_callback
        })
    }
});

同样的效果。我不明白为什么在我的情况下使用Collections。请帮助我用我的例子理解这个概念为什么我必须在这里使用集合。我用Google搜索了很多，可以找到最佳答案。

由于

Answer 1

想象一下，你有两条路线：

/books
/books/:id

现在，要获取特定图书，您可以向/book/:id路线发送请求，其中:id是图书的id。

GET /books/1
< { id: 1, title: 'On the Genealogy of Morality', ... }

如果你想获得所有书籍，会发生什么？您向/books路线发送请求。

GET /books
< [{ id: 1, title: '...', ... }, { id: 2, title: '...', ... }, ...]

Backbone遵循相同的原则。一本书的模型。很多书的集合。当您使用集合时，Backbone会为每本书创建一个模型。将模型用于多个项目是错误的。

你说“Backbone为每本书创建一个模型。”它创造了什么步骤？

它在sync事件上创建模型，即获取所有项目的请求完成时。

......这对我有什么帮助。在我的情况下，我总是拿书，而不是单书。

Backbone Collections总是使用Backbone模型。如果您未明确设置model的{{1}}属性，则Backbone使用普通模型，即Collection的Collection属性应始终引用模型。

model

将模型视为对象，将Collection视为对象数组。

Answer 2

最重要的是，将数据划分为逻辑单元（模型）并将它们分组到类别（集合）中，使您可以轻松地推理，操作和更改数据。一旦你构建的东西甚至比你构建的东西稍微复杂一点，这就成了一个优先事项。关键不在于你获得了一些你无法获得的神奇功能。毕竟这都是javascript。关键是模型和集合提供的数据结构在构建动态应用程序时很有用。实际上，这通常是骨干和MV *的全部要点，以提供有用的工具和抽象。收藏是一系列问题的解决方案，当您为应用添加最微小的额外复杂性时，您将在以后遇到这些问题。

所以，你问为什么你必须使用集合，我猜你已经知道的答案是，你没有有来使用集合。事实上，听起来你根本不需要使用MV *库。

Backbone从模型和集合中获取数据

2 个答案: