將$ scope傳遞給angularJs服務/工廠是一個壞主意？

Question

我正在一個項目中有近90多個模塊。 所有模塊都有一組輸入字段，並且在提交時應將數據保存在服務器上。 在任何給定的時間點，只有一個模塊處於活動狀態。但是在後臺可以打開模塊。

提交按鈕對所有模塊都是通用的，這意味着整個應用程序只有一個提交按鈕。

下面的圖片更多地解釋它。

主要的座右銘是保持個別模塊更改爲最低限度，並從中央位置處理模塊中的某些事情（驗證，重新加載等）。

目前的辦法，我打算是，

• 使用「moduleInit」指令，所有模塊應在其 部分。
• 在指令採用了模塊的$範圍，它只要 模塊是開放的傳遞給 共同服務/工廠（pushConfigService）

• 的pushConfigService商店，並保持這個範圍。一旦範圍被銷燬， 的引用將從pushConfigService中刪除。

• 頁腳面板另有一個指令，在其提交按鈕和 調用在pushConfigService保存功能，這反過來又在模塊中調用 一個$範圍函數來獲取表單數據。

• pushConfigService與一堆其他服務交談，如
  dirtyChecker，apiGenerator並最終將數據發佈到服務器。

每個模塊都有一組使用某些標準名稱定義的作用域方法。例如：_submit，_onSubmit，_cancel，_reload等。

另一種方法來處理這個，廣播提交事件和每個模塊聽相同。有可能更多的行動將被添加到頁腳面板。 所以我有點猶豫使用廣播方式。

我的問題，是否將控制器範圍傳遞給服務是一個好主意？任何替代建議？

在此先感謝。

Answer 1

我相信你的核心理念是處理這種設置的好方法。但我建議從UI中分離業務邏輯。我沒有你的代碼樣本，所以建立一個確切的例子有點困難。然而，既然你使用的是$scope變量，我會假設你沒有使用類似於或類似於John Papa's的styleguide。他的方法鼓勵您不要使用$scope，並保持接近實際的JavaScript「課程」。

這是如何產生影響的？
而不是傳遞整個範圍，你只能通過你的特定模塊的實例。對於你而言，你和同事不需要弄清楚給定範圍的組成，而只需要一個具體的界面來操作就不那麼困惑了。另外它防止服務能夠改變$scope。

後者可以被認爲是一種良好的做法。只要控制器改變範圍，就可以輕鬆找到更改和管理UI的代碼。從那裏控制器可以訪問服務來完成實際的邏輯。

把它一步
所以路過的範圍，而不是類的實例應該是輕鬆的調整到已經提出的設置。但請考慮以下設置。

似乎有很多不同的方式來處理和處理由模塊/最終用戶提供的數據。這個邏輯現在在控制器中實現。有人可能會認爲這些模塊中的一些共享類似的處理方法（在那裏有大的假設）你可以將這個邏輯轉移到可以說是節約戰略的服務中。在激活模塊時，該模塊將在處理提交按鈕單擊的服務中設置其首選的保存策略。或者更確切地說，應該從控制器中的onClick處理程序中調用save數據方法。

現在，這些服務/策略可以在控制器之間共享，可能會設置更好的工作流程和更少的重複代碼。