我应该使用路由器来管理视图的更改吗？目前，我正在使用“父”视图来处理“子”视图管理。
我在一个父母中有多个“子”视图。通过单击链接更改子视图/页面，链接也会修改URL。更改显示的视图由父视图处理 - 而不是路由器。有问题的路由器没有任何有价值的编码，我创建了'虚拟'路由器，所以我可以使用Backbone.history
答案 0 :(得分：0)
我认为您正在搜索某种验证，这是构建应用程序的正确方法。根据您提供的有限信息，很难说，即使您提供了一些代码，您的问题也可能无法明确地回答。
所以，让我这样说吧。我不认为创建由其他视图组成的Backbone.js视图存在任何缺陷。如果您在路由器中放置与视图相关的所有内容，我做认为有问题 - 除非您在那里提供某种高级描述 - 就像传入视图一样，父视图应该显示/附加事件到/其他。
另一点。儿童观点如何相关？他们中的一些可能有一个共同的（高级）接口？或者您的父视图是否包含不同的内容，例如搜索表单和一些网格和标签？或两者？这个父视图是否有可能在另一个页面上有用，或者它只是管理这个特定的页面视图等等。这一切都很重要。
我想甚至可能有理由质疑你的父视图是否应该严格地从Backbone.View延伸，还是应该有其他类型的＆＃34; base＆＃34;类。但是，如果它有效并且与一个＆＃34;视图＆＃34;有一些合理的联系。我不会打扰这个问题。正如杰夫阿特伍德所说，＆＃meta;谋杀＆＃34;。在某些时候，这些讨论变得不切实际，而当仍有重要问题需要修复或实施时，最好留下合理的解决方案。
我的想法是，如果您使用路由器控制并将事物委托给父视图，并让父视图使用它的子视图执行它，您可能没问题。
但是，您可能希望考虑通过路由器中的父视图构造函数传递子视图。拥有一个单独的东西决定一个对象的组成比让对象创建它的组合本身往往更好，但并不总是更好。但总是要考虑透明度。有时，依赖注入所带来的自由并不值得抽象代码的晦涩;特别是如果你不太确定自己在做什么。弄清楚你正在做什么，然后考虑你可能没有想到的抽象。
如果您想知道自己是否做了与社区一致的做某事的方法，您可能应该去backbone.js Google discussion group并在那里复习或提问。