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

Question

我在Ember中实现了一个基本遵循这种布局的应用程序：

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

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

由于输入到我的交互面板非常依赖于与地图视图的交互（绘制多边形，放置标记等），我的这些视图的控制器被设置为“需要”地图控制器。当存在特定的面板视图时，与地图的交互应以各种方式影响面板。

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

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

也许我会以完全错误的方式解决这个问题？是否有其他模式适合我的用例，总是存在不同状态的地图以及与交互面板的相互通信？

Answer 1

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

在每种情况下，我认为模型是你的地图，或者至少是它的“内容”。这些功能实际上是在与您的中心模型进行交互，这是地图，是所有这一切的基础。

所以你真的有一个模型。您可以有效地拥有地图资源，并且可以从URL / API查看该资源上的许多功能路由。

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

所以，TL; DR答案是...通过你的模型和路线......用它们来谈谈你的共同数据：模型是，毕竟，你的数据，控制器和视图只是增加并实现用户体验，演示和互动。

大多数这类架构问题都可以通过在层次结构中上下移动数据来解决（模板视图/组件/控制器/路由/模型），直到找到一个足够低的位置，以便仍然可以访问对象。需要访问它，但足够高，以至于没有被太多的东西紧紧束缚是有道理的，但仍然是在正确的位置并“感觉正确”。

如果它太高，你将倾向于对你的对象做错误的工作（即控制器不应该与视图机制混淆，模型不应该在它们中真正有演示文稿等等。

如果它太低，你将倾向于在框架上做太多的工作，你会倾向于重复自己...即控制器将做很多工作来获得他们需要的数据，例如。