什么时候过滤一个集合与在 Backbone 中拥有多个集合比较合适?
例如,考虑一个音乐库应用程序。它将有一个用于显示流派的视图和另一个用于显示所选流派的音乐的视图。
你宁愿用所有的音乐制作一个庞大的收藏然后过滤它还是几个较小的?
只有一个集合可以让您添加用于按其他属性过滤的功能,但假设您有大量音乐:如果用户只需要一种类型,您如何防止在应用程序启动时将其全部加载?
什么时候过滤一个集合与在 Backbone 中拥有多个集合比较合适?
例如,考虑一个音乐库应用程序。它将有一个用于显示流派的视图和另一个用于显示所选流派的音乐的视图。
你宁愿用所有的音乐制作一个庞大的收藏然后过滤它还是几个较小的?
只有一个集合可以让您添加用于按其他属性过滤的功能,但假设您有大量音乐:如果用户只需要一种类型,您如何防止在应用程序启动时将其全部加载?
我认为最简单的方法是拥有一个通用的唯一集合,该集合智能地fetch
已经被来自服务器的流派数据过滤:
// code simplified and no tested
var SongsCollection = Backbone.Collection.extend({
model: Song,
url: function() {
return '/songs/' + this.genre;
},
initialize: function( opts ){
this.genre = opts.genre;
}
});
var mySongsCollection = new SongsCollection({ genre: "rock" });
mySongsCollection.fetch();
每当用户更改所选类型时,您必须使此集合从服务器重新获取数据:
mySongsCollection.genre = "punk";
mySongsCollection.fetch();
这主要是一种设计选择,但我的投票是选择一种松散地反映存储集合的数据库的方案。
如果您可能将数据存储在 SQL 数据库中,那么您很可能没有单独的表songs
和genres
。您可能会通过genre_id
歌曲表中的列连接它们,或者(如果歌曲可以有多个流派)根据单独的song_genres
连接表来连接它们。因此,您可能需要单独的集合来代表流派和其中的歌曲。在这种情况下,骨干关系可能是非常有用的工具,可以帮助它们保持直截了当。
如果您将信息存储在任何类型的关系/键值/文档存储中,则直接将流派与歌曲一起存储并进行相应过滤可能是有意义的。在这种情况下,您最终可能会以这样一种方式存储您的文档键/查询,以便您可以直接(例如,通过songs
)或通过流派(例如,genre:genre_id/songs
)访问歌曲。如果这是您要走的路,那么简单地创建一个庞大的歌曲集合并计划在应用程序和数据库环境中设置相应的过滤器可能会更方便。