我最近遇到了一些情况，页面上有多个视图需要由单个模型支持。这样，只需修改模型，所有相关视图都会自动更新其外观。问题是，为了实现这个 atm，我需要编写代码来主动寻找这些模型。我偶尔会很幸运，并通过事件处理程序为我提供了一个模型，但通常情况并非如此。我正在寻找一种在页面上一次拥有一个模型实例的好方法，然后在其他任何地方都引用该模型。人们通常如何处理这种需求？Backbone-relational 通过使用草地椅.js 保持一个中央存储来处理它，我听说有人使用一个全局集合来保存所有模型的注册表。
问问题
1639 次
1 回答
4
简短的回答：
一个由多个视图共享的模型（您可以称之为“重复模型”）实际上是一种完全有效（且有用）的主干模式；这根本不是问题。据我所知，这里的问题是很难将该模型放入多个视图中，因此我建议改为解决这个问题。
更长的答案：
将模型传递给多个视图的问题在于它固有地将视图耦合在一起（为了向每个视图提供该共享模型，父视图也需要具有该模型，就像任何“中间”视图一样）。现在，作为程序员，我们被教导要尽可能地封装事物，因此耦合视图一开始可能看起来“错误”。然而，耦合视图实际上是可取的：关键是适当地限制哪些视图是耦合的。
@Shauna 为此提出了一个很好的经验法则：“视图只关心自己并创建它的孩子。” 如果你遵循这条规则，你的视图之间的耦合不会成为问题，你将能够创建灵活、可维护的代码（比使用全局变量更易于维护，因为那样你真的会失去封装）。
鉴于这一切，让我们看一个简单的例子。假设您有视图 A、B 和 C，它们都使用模型 X，但是您在代码中完全不同的位置构建 A、B 和 C（使得它们之间难以共享 X）。
1) 首先，我会看看为什么 A、B 和 C 建在如此不同的位置，看看我是否不能将它们靠得更近。
2）如果它们必须建得如此之远，那么我会看看它们是否有我可以利用的共同点；例如，所有这些点是否都共享一些相关的对象？如果是这样，那么也许我们可以将 X 放在那个对象上，以便与我们所有的视图共享它。
2) 如果 A、B 和 C 之间的代码放置或公共变量没有联系，那么我不得不问“我真的应该在它们之间共享一个模型吗？”
关于作者的无聊故事：
当我第一次开始使用 Backbone 时，我经常会发现自己和同事争论，因为我想做全局变量，他们坚决反对。我试图向他们解释，如果我不能使用全局变量，我必须将模型从视图 A 传递到视图 B，再到视图 C，再到视图 D，再到视图 E，而实际上只有 E 需要该模型。太浪费了！
除了（正如我从那以后了解到的），我错了。至少从可维护性的角度来看，全局变量是一个可怕的想法。一旦你开始使用它们，你很快就不知道是什么代码在影响什么，因为你失去了通常在使用该全局变量的视图之间的封装。如果您正在处理一个有意义的大型项目（即值得使用 Backbone 的项目），封装是保持代码健全的唯一方法之一。
在这期间经常使用 Backbone，我现在坚信正确的答案是在创建模型时将模型传递给视图。这可能意味着在不直接使用它们的中间视图之间传递模型，但这样做会比通过全局传递模型提供更好、更易于维护的代码。一开始可能会觉得很尴尬，但在创建模型时将模型传递给视图是正确的做法。
一旦您对 Backbone 更加熟悉，您可能会发现您很少需要通过多个中间视图传递模型。事实上，您可能会注意到，每当您发现自己必须在多个视图之间传递模型时，您就会检测到“代码异味”，而真正的问题是您的代码需要重构。
但与 Stack Overflow 上的其他所有内容一样，您的里程可能会有所不同；-)
于 2012-12-20T20:47:03.910 回答