使用Ember.js处理控制器间关系的正确方法

我在Ember中实施了一个应用方案，基本上遵循以下布局：

其概念是，用户可以与地图视图（始终存在）上的要素交互，基本导航发生在父视图中的各种视图和任意子视图堆栈之间。用户可以在地图上创建新要素，编辑现有要素等

特定功能的URL可以是/features/123/edit

由于我的交互面板的输入在很大程度上取决于与地图视图的交互（绘制多边形、放置标记等），因此这些视图的控制器设置为“需要”地图控制器。当存在特定面板视图时，与地图的交互应以各种方式影响面板

我的问题是-如何扩展如此紧密的控制器耦合？我基本上需要根据当前激活的面板在不同的贴图模式之间切换。我还认为，我需要观察地图上的事件，并根据当前的活动面板对这些事件采取行动

我设置了一个概念验证，其中某个子视图控制器观察地图控制器的某些属性（例如，使用.obsers（“controllers.Map.activecoords”），但是，即使在用户导航离开特定子视图之后（即，一旦控制器初始化），这样的观察者仍将继续触发.在进入和离开路线时，我必须手动设置和拆除这些观察者（即使用addObserver）吗？这是正确的模式吗？我得到的印象是，我需要在过渡期间手动删除所有这些观察者，以避免意外行为和内存泄漏

---

也许我完全走错了方向？有没有其他模式适合我的用例，它具有不同状态的始终存在的映射以及与交互面板的交互？

也许应用程序的体系结构不应该连接控制器，而应该问问你自己“这里的模型是什么，真的？”

在每一种情况下，我认为模型就是你的地图，或者至少是它的“内容”。这些特性实际上是在装饰与你的中心模型的交互，这就是地图，它是一切的基础

实际上，这里只有一个模型，从URL/API上看，实际上有一个地图资源和该资源上的许多功能路由

现在的问题不是“如何管理控制器之间的依赖关系层次结构”，而是“如何管理同一模型上的视图和子视图？”？“这在标准的ember嵌套路线中得到了非常简单的回答。您的外部视图始终存在，并且它有一个出口，这就是您的功能所在。它的渲染方式与标准嵌套路线的渲染方式相反，但它是相同的模式

<太长了，读不下去了……回答你的常用数据：模型毕竟是你的数据，控制器和视图只是在增加，并使用户体验、呈现和交互。 大多数此类体系结构问题都可以通过在层次结构（模板视图/组件/控制器/路由/模型）上下移动数据来解决直到你找到一个地方，它足够低，仍然可以让需要进入它的对象进入，但足够高，没有被太多东西紧紧束缚，它是有意义的，但仍然在正确的位置和“感觉正确”

如果它太高，你将倾向于对你的对象做错误的工作（即控制器不应该弄乱视图机制，模型不应该真的有演示内容，等等）

---

如果它太低，你会倾向于对框架做太多的工作，你会倾向于重复你自己很多…例如，ie控制器会做很多工作来获取他们需要的数据。

jsbin或一些代码会很有帮助，我可以尝试从我的设置中提取一些相关的部分，但是，我更感兴趣的是如何在概念上实现这一点，而不是可能涉及到的确切操作。例如，当某些控制器视图当前未处于活动状态时，控制器如何与观察员耦合，而不在后台发生任何事情。我不确定Ember是否有一个通用的习语来描述您想要的内容。Ember倾向于考虑它的所有数据（模型、控制器、路由、模板等）非常分层，其中单个节点是重点。我要做的第一件事（只是让它工作），就是在控制器上放置

active

属性，如果

false

则拒绝响应操作。从这里开始，我认为找到一个干净、有效的习惯用法只是反复尝试。我不确定这是否正确，因为可能会重复