將控制器從與服務器交互的服務中解耦出來的任何好處

在Angular.js中，我想知道在控制器和向服務器發出請求的服務之間是否有其他接口的好處。將控制器從與服務器交互的服務中解耦出來的任何好處

我最近一直這樣做的，我真的不能告訴我們，如果這是完全沒有意義的有這個額外一跳，如果這是真的一樣的握手僅在中間一個額外的手，等

所以我有一個控制器，然後注入該控制器的服務。該服務注入實際的「服務器請求服務」，並用回調或pub/sub向控制器報告。

感謝您的任何意見。

2014-11-15 Scott Jason

如果你的模型（數據實體）與你想要ViewModel的方式有很大的不同，那麼這樣做會有好處。該圖層可以進行轉換。 –

我想說這取決於您的服務的主要目的。讓我得到它的權利基本上是你有這樣的：

Controller A 
| 
|--> Service Main 
    | 
    |--> Service Ajax

所以我們說的主要服務是完整的業務邏輯，而這依賴於阿賈克斯的查詢。但是，基於每個客戶，ajax查詢本身可能有不同的實現。在這種情況下，您的解耦方案可能更容易更快地交換它們。除此之外，任何數據轉換（如合併來自不同來源的多個請求等）均可在此處完成，而您的主控制器只是維護與您的應用程序相關的邏輯。但在這一點上，它似乎更像是一種個人風格，而不是一種最佳建議規則。

我強烈建議的是最大限度地減少pub/sub的使用（以防使用$ broadcast/$ emit），因爲這會帶來很多開銷，特別是在更大的應用程序中。而不是嘗試從ajax-query一直回到控制器。

來源

2014-11-15 07:16:51 zewa666

在接口服務中實際上沒有業務邏輯發生（導致我到這篇文章的一半）。這就是說，只有每個控制器都有自己獨特的接口服務，只有這樣才能避免將單個AJAX服務直接注入到每個控制器中，而這些都依賴於它。所以有這個額外的跳躍，以避免直接注入。我不明白的是，這是否實際上創造了一個分離實體的好處。似乎控制器只是與其他問題有點隔離。而且沒有Angular pub/sub。我正在使用中介模式服務。 –

因此來自服務器的數據被返回到接口。回撥給控制器。沒有pub/sub。 –

將控制器從與服務器交互的服務中解耦出來的任何好處

回答

相關問題