javascript-Backbone.js-如何处理具有相同ID和类型的多个模型？或者如何避免这种情况

最近,我遇到了一些情况,其中页面上有多个视图需要单个模型支持.这样,只需修改模型,所有相关视图将自动更新其外观.问题是,为了实现这一atm,我需要编写主动寻找这些模型的代码.我偶尔会很幸运,并通过事件处理程序提供了一个模型,但是通常不是这种情况.我正在寻找一次在页面上同时具有一个模型实例的好方法,然后在其他地方仅引用该模型.人们通常如何处理这种需求？骨干关系服务器通过使用grasschair.js来保留一个中央商店来处理它,而且我听说有人使用单个全局集合来保存所有模型的注册表.

解决方法:

简短答案：

一个由多个视图共享的模型(您可以将其称为“重复模型”)实际上是一种完全有效(且非常有用)的骨干模式.这根本不是问题.从这里我可以说出的问题是,很难将模型引入多个视图中,因此我建议解决这个问题.

更长的答案：

将模型传递给多个视图的问题在于,它固有地将视图耦合在一起(为了向每个视图提供该共享模型,父视图也必须具有该模型,就像任何“中间”视图一样).现在,作为程序员,我们被教导要尽可能地封装所有内容,因此乍一看耦合视图似乎“错误”.但是,实际上需要一对视图：关键是要适当地限制耦合的视图.

@Shauna为此建议了一个很好的经验法则：“视图只关心自己并创建它的子对象.”如果遵循此规则,视图之间的耦合将不会成为问题,并且您将能够创建灵活的,可维护的代码(与使用全局变量相比,可维护性要高得多,因为那样的话,您将真的失去封装性) ).

考虑到所有这些,我们来看一个简单的例子.假设您有全部使用模型X的视图A,B和C,但是您正在代码中完全不同的位置构建A,B和C(这使得它们之间很难共享X).

1)首先,我将研究为什么在这样的不同位置构建A,B和C,并查看是否无法将它们靠得更近.

2)如果必须将它们构建得相距太远,那么我将查看它们是否具有可以利用的共同点；例如,所有这些地点都共享某个相关对象吗？如果是这样,那么也许我们可以将X放在该对象上,以与所有视图共享它.

2)如果代码放置或A,B和C之间的公共变量没有任何联系,那么我不得不问：“我真的应该在它们之间共享模型吗？”

关于作者的无聊故事：

刚开始使用Backbone时,我经常会发现自己在与同事吵架,因为我想创建全局变量,而全局变量却坚决反对.我试图向他们解释,如果我不能使用全局变量,那么当只有E实际需要该模型时,我必须将模型从视图A传递到视图B,将视图C传递到视图D,将视图E传递出去.太浪费了！

除了(自从我学习以来),我是错的.至少从可维护性的角度来看,全局变量是一个可怕的想法.一旦开始使用它们,您很快就不会知道哪个代码会影响什么,因为您会丢失通常在使用该全局变量的视图之间使用的封装.而且,如果您正在从事一个有意义的大型项目(即值得使用Backbone进行开发的项目),则封装是使代码保持健全的唯一方法之一.

在两次之间使用Backbone的时间很多,我现在坚信正确的答案是在创建模型时将模型传递给视图.这可能意味着在不直接使用它们的中间视图之间传递模型,但是与通过全局变量传递模型相比,这样做将为您提供更好,更可维护的代码.乍一感觉很尴尬,在创建模型时将模型传递给视图是正确的做法.

一旦您对Backbone更加熟悉,您可能会发现您几乎不需要通过多个中间视图传递模型.实际上,您可能会注意到,每当发现自己不得不在多个视图之间传递模型时,就已经检测到“代码异味”,而真正的问题是您的代码需要重构.

但与Stack Overflow上的所有其他内容一样,您的里程可能会有所不同;-)

标签：backbone-js,models,backbone-relational,javascript
来源： https://codeday.me/bug/20191031/1976104.html