2015-09-05 53 views
1

我已經創建了一個用於存儲(add)一BookService,得到(getAll)和刪除(remove)書籍Angular.js方法複製的控制器。現在我想在我的控制器中使用這個BookService發佈一些方法,以後我可以在我的視圖中使用。我的控制器看起來如下:當使用服務

app.controller('BookController', ['BookService', '$scope', function(BookService, $scope) { 

    $scope.addBook = function() { BookService.add(); } 
    $scope.getAllBooks = function() { BookService.getAll(); } 
    $scope.removeBook = function() { BookService.remove(); } 

}]); 

正如你所看到的,控制器只是轉發該方法調用該服務的代理。這通常是不好的做法?有沒有更好的方法來解決使用Angular.js?在沒有控制器的情況下直接從視圖調用服務似乎對我來說是一個更大的問題。

回答

1

你顯示的是不錯的做法;實際上建議您將資源管理邏輯(如添加,刪除和查找相同類型的資源)抽象爲單獨的服務,以實現組織和可維護性以及可重用性目的。

我明白你的例子控制器似乎只是代理服務,但爲什麼你會認爲它是重複的,可能是多餘的。讓我展開你的例子,看看我能否解釋抽象邏輯的理由。在這樣做的時候,我們只考慮添加操作,即使邏輯也適用於其他操作。

原因1:在網絡應用程序中添加書籍(或任何資源)通常比調用bookService.add()更復雜。它需要有某種形式來輸入詳細信息,一個提交按鈕來處理實際的請求,可能對所輸入的數據進行按摩,添加新時間戳和作者ID等字段,並堅持一些數據存儲。前兩個或三個步驟適用於您添加的屏幕或視圖,因此將其放入控制器(視圖模型)中是有意義的,而其餘步驟應放入通用服務中。

現在,假設您有另一個屏幕,您可以看到朋友的書籍列表,並可以通過選擇一本書將其添加到列表中。在這種情況下,該視圖的控制器的控制器邏輯將與前面的示例不同,但服務步驟仍然相同,因此無需重複,因爲服務可以注入到兩個控制器中。

這是一個很大的勝利。

示例2:假設您已經按照上面示例1中的描述將控制器和服務之間的代碼分開。然後你決定你的數據存儲需求已經改變,現在你想更新你的邏輯以保存到不同的數據庫系統。現在,不必更換所有的控制器,只需更改服務和一切正常。

這也是一個非常大的勝利。

2

最佳實踐

從我可以看到這是非常好的做法,我假設你使用$scope這裏這些服務綁定到一個按鈕或類似的東西。使用工廠或服務的想法是創建一些組織良好的可重用代碼,然後您可以像控制一樣在控制器中實例化。

控制器可能會變得非常複雜,因此將基本功能移到服務中是最好的選擇。在你的情況下,你有一個相對簡單的控制器,所以你可能不會看到以這種方式編碼的好處。但是我向你保證,隨着你的代碼庫的增長,你將被要求像這樣編寫代碼,以保持可讀性。

注意

只是作爲一個額外的筆記我添加了你可能需要與數據庫請求的例子

database > API > service/factory > controller > view 

這將是正確的路該如何走當數據處理從數據庫請求一些東西。

0

是的,你已經做到了這一點。請記住,隨着您擴展應用程序的複雜性,您將需要分離範圍,(和)分解爲組件指令。每個指令都有自己的控制器和模板片段。