主干关联vs主干关系

我一直在寻找有关如何在Backbone中建立关系的信息，并遇到以下两个不错的插件:

Backbone-relational
Backbone-associations

两者似乎都存在了两年多，并且似乎很稳定。然而，Backbone-relational在以下方面优于Backbone-associations:

提供几乎所有的关系，如one-to-one, one-to-many, many-to-one，因为我们有在数据库
第一眼看到很好的文档(类似于Backbone.js)

由于我没有时间广泛地浏览这两个插件，我想从有经验的人那里了解以下事情:

如何容易使用插件与后端服务器如Ruby on Rails?
实现多态关系有多容易?

最大的区别是Backbone-relational不允许创建具有相同id的相同模型的多个实例。考虑:

let Person = Backbone.RelationalModel.extend({
    relations: [
        type: Backbone.HasMany,
        key: 'likes_movies',
        relatedModel: 'Movie'
    ]
});
let peter = new Person({
    likes_movies: [{id: 1, title: 'Fargo'}, {id: 2, title: 'Adams Family'}]
);
let john = new Person({
    likes_movies: [{id: 1, title: 'Fargo'}, {id: 2, title: 'Adams Family'}]
);
// Change title of one of Peter's movies
peter.get('likes_movies').get(1).set('title', 'Fargo 2 (Sequel)');
// John's corresponding movie will have changed its name
console.log(john.get('likes_movies').get(1)); // Fargo 2 (Sequel)

如果为Backbone-associations重写，约翰的电影标题就不会改变。这可以被认为是一个功能或缺点，这取决于你如何看待它。

除此之外，这两个库非常相似，除了Backbone-associations的开发似乎在一年前就停止了。

实际上，基于GitHub脉冲(活动指标)，骨干关系社区似乎更活跃。

当我在寻找像EmberData或Restangular这样的东西时，我研究了这两个库。

这两个库都试图弥补主干的主要弱点:正确处理Rest API Restful资源。
事实上，每次需要渲染时，Backbone都会促进新模型的创建(而不是重用应用程序中其他地方用于渲染的实例)。
由于一些模型更新没有在web应用程序的所有地方传播，因此会出现一些不一致。
然后需要骨干模型实例的缓存。主干关系提供这样的缓存，但主干关联没有。

此外，它们都重新实现了Backbone的代码方法(set, get, reset, trigger)，因此它们与Backbone强耦合。
这可能会使主干库迁移变得复杂，特别是如果你在主干之上使用另一个MVC框架(Marionnette, Thorax, Chaplin，…)

骨干网关联在代码行数方面比骨干网关系更少(800 vs 2000)。

骨干关联实现更容易调试，因为它直接将关系管理到重载方法(set, get，…)
相反，骨干关系依赖于队列将关系内容与其内部存储同步。这使得调试变得棘手…

另一个轻量级(但较少使用)的替代方案是"Backbone SuperModel": http://pathable.github.io/supermodel/

这个库是800行代码的复合，比Backbone Relational更容易理解(我能够自己修复一个小错误)。
它提供了一个基于backbone Collection的骨干实例缓存

在我身边，

我成功集成了最后一个与RequireJs
我管理与它的一些多态性关联
我的web应用程序和我的Java后端之间的协议出现了
每次需要时我都成功升级主干和木偶

相关内容

最新更新

热门标签：