长话短说，假设一个应用有多个页面：
我的问题是，女巫是首选的 Backbone 处理方式，为什么（请论证）？
定义分页视图、分页集合、搜索模型、搜索视图等，并在所有必要的页面中将每个视图初始化为子视图。这意味着我们必须将子视图元素附加到“主”元素中，并在所有必要的页面中处理它们之间的所有通信。
定义一个分页视图（使用它自己的分页集合和搜索模型）并将其扩展到所有必要的页面。这确实意味着我们将不得不使用模板部分（用于表单、分页等）并绕过处理子视图之间通信的需要，同时也无需添加/删除子视图元素。
李>如果上面没有找到这些情况，请添加你的处理方式，记得争论。
我个人的意见是 2。那是因为它消除了子视图之间的大量交流，并且仅通过扩展类就可以使所有内容更易于阅读，而不必“手动”初始化子视图。它还提供了在需要时重写每页行为的选项。
【问题讨论】：
标签： backbone.js
我认为#2 是一个糟糕的选择。
让模板尽可能简单是个好主意。它们基本上只是为某些输入对象生成的标记。为了将该对象获取到模板中，在 MV* 框架中，您有视图，它可以将模型传递给模板或将一些格式化数据发送到模板（我更喜欢在可能的情况下这样做）。
Partials 只是创建标记。您仍然需要处理事件、更新 DOM 和在视图中渲染。如果您只使用一个视图，它将不得不处理很多事情，这些事情与可维护性差和更容易出错的代码库相关。 您要么在视图中有大量代码，要么最终得到大量 mixin 或进行大量继承 - 我不知道哪个更糟。
大事情更难测试和推理。避免做大事。
我认为模板部分方法的另一个大问题是，您不能依赖类型信息（类似于接口）和模板中的对象。当你有一个或两个你刚刚创建的部分时，它可能很容易让它工作，但是，随着时间的推移，这些信息会丢失，导致糟糕的开发体验。
您需要确保与您的更改无关的视图会随着您刚刚对某项功能所做的部分更改而保持更新。
请记住，软件永远不会完成。事情总是在变化。
您将面临另一个需要处理的复杂挑战：通过局部视图耦合视图，而不是考虑模型之间的关系。
替代方案要好得多。组合专门的视图是一种很好的方法，因为每个视图都有自己的内部、较小的状态，并且只会在发生某些操作时通知侦听器。没有人关心那里发生了什么，直到发生了一些事情，然后你就得到了具体的数据。
使用 #1 可帮助您处理应用程序中的复杂性，同时允许您在其他情况下重用它们。
【讨论】：