正確的方式來處理與Ember.js

Question

控制器間的關係我在灰燼實現的應用方案，基本上遵循這樣的佈局：

的概念是，用戶可以在互動功能地圖視圖（始終存在）和基本導航發生在父視圖中的各種視圖和任意的子視圖堆棧之間。用戶可以在地圖上創建新的功能，編輯現有的等

特定功能的URL可以是/特徵/ 123 /編輯

由於輸入到我的交互面板是非常依賴與互動地圖視圖（繪製一個多邊形，放置一個標記等）我的這些視圖的控制器被設置爲「需要」地圖控制器。當存在特定的面板視圖時，與地圖的交互應以各種方式影響面板。

我的問題是 - 如何做一個規模如此緊張的控制器結合？我基本上需要根據哪個面板當前處於活動狀態在不同的地圖模式之間切換。我相信，我也需要觀察地圖上的事件，並根據當前的活動面板採取相應的行動。

我設置了某個子視圖控制器觀察地圖控制器的某些屬性（例如.observes（「controllers.map.activecoords」））的概念證明，但是，這樣的觀察者將繼續觸發用戶已經從特定的子視圖導航（即一旦控制器被初始化），我必須在進入和離開路徑時手動設置和拆除這些觀察者（即使用addObserver）嗎？這是正確的模式嗎？我得到了一個印象，那就是我需要在轉換過程中手動刪除所有這些觀察者，以避免出現意外行爲和內存泄漏。阿瓦ys目前的地圖與不同的國家和互動面板互通？

Answer 1

也許你的應用程序的架構不應該是連接控制器，而是問自己「什麼是模型在這裏，真的嗎？」

在每一種情況下，我認爲該模型是你的地圖，或至少其「內容」。這些功能確實能夠與中心模型（即地圖）之間的相互作用進行裝飾。

所以真的是你在這裏有一個單一的模式。從URL/API查看，您實際上擁有一個地圖資源以及該資源上的許多功能路由。

現在的問題是沒有這麼多「如何管理控制器之間的依賴關係層次？」因爲「如何管理同一模型中的視圖和子視圖？」這在標準的ember嵌套路由中很簡單地回答。您的外部視圖始終存在，並且它有一個出口，這是您的功能所在的位置。它的渲染方式與標準嵌套路由的渲染方式相反，但它仍然是相同的模式。

因此，TL; DR答案是...去通過你的模型和路線......用它們來談談你的通用數據：該模型是，畢竟，你的數據，以及控制器和視圖僅僅是增強和啓用用戶體驗，呈現和交互。

大部分這些架構問題都可以通過向上和向下移動層次結構（模板視圖/組件/控制器/路徑/模型）來解決，直到找到足夠低的位置以便仍然可以訪問對象需要訪問它，但又足夠高，因爲它不會被太多的東西束縛而變得有意義，但仍然處於正確的位置並且「感覺很好」。

如果它是太高，你會傾向於做了錯誤方面的工作與你的對象（即控制器不應該與視圖力學碴，車型實在不應該在他們演示的東西，等

如果它太低，你會傾向於在框架上做太多的工作，你會傾向於重複自己很多...即控制器將會做很多工作來獲得他們需要的數據，例如：