Model view controller Ember.js 1.1.x：路由器的责任

有人能简要地总结一下，哪些责任应该由恩伯的路由系统来处理吗

在与灰烬相处了两周后，我突然觉得我对路由的作用没有一个准确的把握。它看起来好像无所不能；建立URL、设置任意控制器/模板/etc、转发路由、模型加载前/加载后事件等

---

Ember路由的广泛功能让我不确定路由器与MVC对象应该处理什么。官方文件（）很好地解释了如何做很多事情，但有点让我看不到森林中的树木……

我发现了一篇关于路由的非常简洁和解释性的博客帖子：

理解在Ember.js应用程序中正确使用路由器是该框架的一个基本核心概念。文档告诉我们，路由器将URL转换为一系列嵌套模板，几乎所有可用的教程都显示了如何嵌套路由，作为路由器工作原理解释的一部分

当您想要一个包含项目列表的UI时，这非常好 同时显示单个项目。这就留下了许多初学者 然而，当他们试图替换一个 使用另一个路由的模板创建页面。今天我们将探讨两种方法 解决这个问题

---

概念模型

考虑这个问题的一种方法是，在MVC术语中，路由和控制器都是控制器。控制器负责控制模型及其显示之间的连接，以及数据的进出，路由负责控制模型之间、模型与应用程序之间以及模型与其持久层之间的连接

应用：祖父模型

在这个视图中，应用程序是祖父模型（它总是存在的：即使您没有显式地引用它，也会匿名创建一个ApplicationRoute和ApplicationController）。因此，路由自然控制应用程序与其他模型之间的连接

最常见的设置

对于给定的模型，通常（作为基本起点）有两条路由和两个控制器。一个路由管理模型集合的检索，一个相应的控制器将该集合连接到集合的视图，另一个路由管理模型单个实例的选择，将其绑定到管理其与视图的连接的控制器

谁处理行动？

视图、路由和控制器都可以拦截和处理操作。他们每个人都有其他人没有的特殊能力

管制员的特殊能力

控制器的特殊功能是，它们知道操作所涉及的模型的特定实例或集合。如果某个动作发生在某个控制器上，则该动作通常起源于与该控制器的模型相关的视图元素。因此，在控制器上定义的操作应该对模型或模型集合执行某些操作。如果操作不关心模型/集合，则它可能属于路由

路线特殊能力

Routes的特殊功能是，它们知道模型/集合组织到的层次结构。这意味着它们可以比控制器更自然地完成与导航相关的事情

查看特殊能力

视图的特殊功能是它们了解界面、事件和动画等

使用多个处理程序处理操作

虽然没有必要，但我经常将一个操作拆分为两个（甚至三个）处理程序，通常使用相同的名称。在两种情况下，一个处理程序位于控制器上，并执行与选择、查询或以其他方式与模型对话有关的部分操作。另一个处理程序位于路线上，负责操作的导航部分。当动作以这种方式分解时，你会发现你的应用程序变得更容易重构，你需要做更少的练习来适应视图html结构中的“古怪”（特别是对于像取消或取消选择这样的负面动作）

有时，第三个处理程序存在于视图中，并执行jquery或css动画。在每种情况下，当一个组件完成了其部分操作时，它使用

send

将该操作转发给下一个应该处理该操作的组件。通常这意味着查看->控制器->路线

摘要

---

总之，Routes应该专注于管理模型的检索以及模型之间以及模型与应用程序之间的连接，处理与导航和应用程序状态相关的部分操作。控制器应重点管理模型与html视图元素的连接，处理与选择/取消选择/修改特定模型或模型集合有关的操作部分（注意：选择通常是切换到新路由，并由路由处理。但有时控制器会处理非路由选择，例如通过从另一个模型的列表中选择项目来设置一个模型的属性）。视图应该处理与更改它们所表示的html有关的部分操作，例如，动画、反映状态的css更改等。

我看到Emberjs.org指出了路由器和“路由处理程序”之间的区别。我怀疑我的部分困惑来自于对这一区别的不完全理解。Michael，这是一份很棒的书面文件非常有帮助，特别是“最常见的设置”部分。我看到很多路由器为模型设置数据（通常是虚拟数据）的示例。远程数据应该由模型还是路由获取？