我应该使用路由器来管理视图的变化吗？目前，我正在使用“父”视图来处理“子”视图管理。
我在一个父母中有多个“孩子”观点。通过单击链接更改子视图/页面，这也修改了 URL。显示视图的更改由父视图处理，而不是路由器。有问题的路由器没有任何价值编码，我创建了“虚拟”路由器，所以我可以使用Backbone.history
问问题
53 次
1 回答
0
我想您正在寻找某种验证，证明这是构建您的应用程序的正确方法。从您提供的有限信息来看，很难说，即使您确实提供了一些代码，您的问题也可能无法明确回答。
所以，让我这样说吧。我认为创建由其他视图组成的 Backbone.js 视图没有任何缺陷。如果您将与视图更改相关的所有内容都放在路由器中，我确实认为有问题 - 除非您在那里提供某种高级描述 - 例如传入视图，父视图应该显示/附加事件到/某物别的。
还有一点。孩子的观点是如何关联的？他们中的一些人可能有一个通用的（高级）接口吗？或者您的父视图是否包含不同的东西，例如搜索表单和一些网格和标签？或两者？这个父视图是否有可能在另一个页面上有用，或者它只是要管理这个特定的页面视图等等。所有这些都很重要。
我想甚至可能有理由质疑您的父视图是否应该严格扩展Backbone.View或应该具有某种其他类型的“基”类。但是，如果它有效并且与成为“观点”有某种合理的联系，我就不会费心问这个问题了。正如 Jeff Attwood 所说，“元是谋杀”。在某些时候，这类讨论变得不切实际，当仍有重要问题需要解决或实施时，最好留下合理的解决方案。
我的想法是，如果您使用路由器来控制并将事情委托给父视图，并让父视图用它的子视图来做这件事，那么您可能没问题。
不过，您可能需要考虑通过路由器中父视图的构造函数传入子视图。让一个单独的事物决定一个对象的组合通常比让对象自己创建它的组合更好，但并不总是更好。但也要始终追求透明度。有时，通过依赖注入获得的自由并不值得抽象代码的迟钝；特别是如果你不太确定自己在做什么。弄清楚你在做什么，然后考虑你可能没有想到的抽象。
如果你想知道你做的事情是否与社区做某些事情的方式一致，你可能应该去主干.js 谷歌讨论组，并在那里审查或提出问题。
于 2012-09-04T18:01:58.593 回答