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