谁能简明扼要地总结一下 Ember 的路由系统应该处理哪些职责？
在使用 Ember 2 周后，我突然觉得我没有准确掌握路由的作用。它看起来无所不能；建立 url，设置任意控制器/模板/等，转发路由，模型的前/后加载事件等。
Ember 路由的广泛功能让我不确定路由器与 MVC 对象应该处理什么。官方文档 (http://emberjs.com/guides/routing/) 很好地解释了如何做很多事情，但有点阻止我只见树木不见森林......
【问题讨论】：
标签： model-view-controller ember.js url-routing
概念模型
一种思考方式是路由和控制器都是 MVC 命名法中的控制器。控制器负责控制模型及其显示之间的连接，以及将数据传入和传出模型，路由负责控制模型之间、模型与应用程序之间以及模型与其持久层之间的连接。
应用：祖父模型
在此视图中，Application 是祖父模型（它始终存在：即使您没有明确引用它，也会匿名创建 ApplicationRoute 和 ApplicationController）。所以很自然，路由控制着应用程序和其他模型之间的连接。
最常见的设置
对于给定的模型，通常会有（作为基本起点）两个路由和两个控制器。一个 Route 管理 Model 集合的检索，对应的 Controller 将该集合连接到该集合的视图，另一个 Route 管理 Model 的单个实例的选择，将其绑定到一个控制器，该控制器管理其与一个视图。
谁负责操作？
视图、路由和控制器都可以拦截和处理动作。他们每个人都有其他人没有的特殊能力。
控制者特殊能力
控制器的特殊能力是他们知道动作所关注的模型的特定实例或集合。如果一个动作到达控制器，它通常源自与该控制器模型相关的视图元素。因此，在控制器上定义的动作应该对模型或模型集合做一些事情。如果一个动作不关心模型/集合，它可能属于 Route。
路线特殊能力
Routes 的特殊能力是它们知道模型/集合被组织成的层次结构。这意味着他们可以比控制器更自然地完成与导航相关的事情。
视野特殊能力
Views的特殊能力是他们知道界面，事件动画等。
使用多个处理程序处理操作
虽然没有必要，但我经常将一个操作拆分为两个（甚至三个）处理程序，通常使用相同的名称。在两个的情况下，一个处理程序位于控制器上，并执行与选择、查询或以其他方式与模型对话有关的部分操作。另一个处理程序位于一条路线上，并关注操作的导航部分。当以这种方式拆分操作时，您会发现您的应用程序变得更容易重构，并且您必须做更少的体操来适应视图的 html 结构中的“怪异”（特别是对于取消或取消选择等负面操作）。
有时第三个处理程序存在于视图上并执行 jquery-ish 的事情或 css 动画。在每种情况下，当一个组件完成了它们的动作部分时，它使用send 将动作转发给应该处理它的下一个组件。通常这意味着 View->Controller->Route。
总结
总而言之，Routes 应该专注于管理模型的检索以及它们之间以及它们与您的应用程序之间的连接，处理与导航和应用程序状态有关的操作部分。控制器应该专注于管理模型与 html 视图元素的连接，处理与选择/取消选择/修改特定模型或模型集合有关的操作部分（注意：选择通常是切换到新路由，并由 Route.但有时控制器会处理非路由选择，例如通过从另一个模型的列表中选择一个项目来设置一个模型的属性）。视图应该处理与更改它们所代表的 html 有关的操作部分，即动画、反映状态的 css 更改等。
【讨论】：
我找到了一篇关于路由的非常简洁和解释性的博文：http://hashrocket.com/blog/posts/ember-routing-the-when-and-why-of-nesting
了解在 Ember.js 应用程序中正确使用路由器是该框架的基本核心概念。文档告诉我们，路由器将 URL 转换为一系列嵌套模板，几乎所有可用的教程都展示了如何嵌套路由，作为路由器工作原理的一部分。
当您想要一个显示项目列表的 UI 时，这非常有用 同时显示单个项目。这让很多初学者 然而，当他们试图替换 带有另一条路线模板的页面。今天我们将探讨两种方法 解决这个问题。
【讨论】：