ember.js是否鼓励过多的控制器？

我试图了解构建ember.js应用程序的最佳实践。这张来自tomdale的幻灯片：

简要描述了如何分配应用程序逻辑。然而，在尝试遵循这些准则时，我发现了一些问题：

路由器变得太大了。根据演示，路由器“响应来自视图的事件”，但当有几十个视图时，这会产生大量代码

有大量的控制器。在Rails应用程序中，CRUD操作通常驻留在同一个控制器中，但是对于ember应用程序，似乎应该有一个控制器来列出记录，一个用于查看记录，一个用于创建记录，等等

感觉不是很枯燥，因为在控制器、视图和把手模板之间有太多的文件，每个模板只有几行代码

我试图确定问题是否在于我错误地应用了这些指导原则，或者这些指导原则是否只适用于琐碎的应用程序

---

有人有什么建议吗？特别是关于如何管理路由器的增长？

我认为我们正在开发一个相当大的ember应用程序（目前大约有45个视图）。这意味着控制器和模板的数量几乎相同）。 的确，我们的路由器相当大，但我们通过将其拆分为多个文件来轻松管理它。基本上，每个文件代表应用程序的一个屏幕，并负责维护一个功能集。以下是路由器的摘录：

Router=Ember.Router.extend({
根：Ember.Route.extend({
索引：Ember.Route.extend({
路线：“/”，
未锁定：Ember.Route.extend({
路线：“欢迎”，
连接插座：功能（路由器）{
var applicationController=router.get（'applicationController'）；
applicationController.connectOutlet（“欢迎”）；
}
}),
记录：Ember.Route.extend({
路线：“应用程序”，
项目：Ember.Route.extend({
路线：“项目”，
收藏：ProjectsRoute，
成员：ProjectRoute，
展示项目：功能（路由器）{
router.transitiono（'projects.collection'）；
}
})
})
})

然后在

ProjectRoute

中也一样。每次在一个路由中似乎有很多功能，我们都会将其拆分。 您甚至可以重新打开一个路由来扩展它，并在其中插入其他功能

ProjectState.reopen({
场景：场景路线，
展示场景：功能（路由器）{
router.transitiono（'scenarios.collection'）；
}
});

这意味着需要更多的文件，但有了一个良好的组织，维护起来并不困难，因为您很少同时处理所有功能。通常，我不会同时打开4个以上的文件（视图、控制器、模板、路由）

---

我不知道这是否是一个最佳实践，但它对我们来说效果相当不错

我认为说Ember鼓励了太多的控制器就像说Javascript鼓励了太多的函数一样。是的，你可能会对其中任何一个的激增感到疯狂。或者你可以做相反的事情，让它完全按照你的需要工作。总的来说，请记住r应用程序应该和它需要的一样复杂，不再如此。你不需要仅仅因为某个著名的程序员使用了某个架构或模式，也不需要因为它似乎是“余烬之路”。即使是“通用的好东西”，如关注点分离、MVC等，都是你应该尝试理解的原则和模型我认为，有选择地以正确的理由打破规则和模式的能力，与其说是对编程之神教条的盲目崇拜，不如说是一个伟大黑客的标志。这是一种技艺，而不是一种宗教。（但是YMMV。也许有一个特别的地狱圈是留给像我这样的程序员的。我打赌不是这样。）

具体到Ember，我倾向于在数据模型和/或特定用户工作流周围使用控制器，而不是在每个视图周围。然后使用路由/状态管理器作为视图之间的粘合剂，我通常在视图上使用事件管理器来处理每个视图中的浏览器事件，包括向路由器发送指令。因此，如果我作为一个围绕客户和产品的应用程序，我将为每个应用程序配备一个控制器，就像我在Rails中所做的那样。这将导致每个控制器拥有的函数和计算属性比某些人希望在一个地方拥有的要多。这也意味着我不一定能够在其他环境中重用我的视图，因为它们是硬的是的，这是一个很差的关注点分离。但如果它导致了没有回报的复杂性，那就不是绝对好的

同样关于控制器，我认为人们特别倾向于为主数据模型的子集增加不必要的控制器。假设你有一个产品控制器，并且你想将给定用户收集的产品存储在一个比较工具中。大多数人似乎为此创建了一个新的控制器，但这是完美的合法的做法是将它们放入产品控制器或客户控制器内部或客户模型上的附加数组或其他可枚举项中。这将使依赖相同函数和属性的对象保持在更近的范围内。每个控制器中的

内容

对象，可以说，只是另一个可枚举项。它有一些特殊的对控制器的隐式引用，但不是神奇的。我没有发现不使用附加引用的功能性原因。它们与绑定、与

#每个
等一样有效

类似地，有些人只是喜欢将他们的应用程序分解成一百万个文件，将它们嵌套在文件结构中15个深度，等等。如果这有助于你可视化基本逻辑，并让团队的其他成员明白，那么你就有了更大的能力。对我来说，这只会让我在只有1-3人的工程团队的项目上放慢速度