当使用服务

Question

我已经创建了一个用于存储（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？在没有控制器的情况下直接从视图调用服务似乎对我来说是一个更大的问题。

Answer 1

你显示的是不错的做法;实际上建议您将资源管理逻辑（如添加，删除和查找相同类型的资源）抽象为单独的服务，以实现组织和可维护性以及可重用性目的。

我明白你的例子控制器似乎只是代理服务，但为什么你会认为它是重复的，可能是多余的。让我展开你的例子，看看我能否解释抽象逻辑的理由。在这样做的时候，我们只考虑添加操作，即使逻辑也适用于其他操作。

原因1：在网络应用程序中添加书籍（或任何资源）通常比调用bookService.add()更复杂。它需要有某种形式来输入详细信息，一个提交按钮来处理实际的请求，可能对所输入的数据进行按摩，添加新时间戳和作者ID等字段，并坚持一些数据存储。前两个或三个步骤适用于您添加的屏幕或视图，因此将其放入控制器（视图模型）中是有意义的，而其余步骤应放入通用服务中。

现在，假设您有另一个屏幕，您可以看到朋友的书籍列表，并可以通过选择一本书将其添加到列表中。在这种情况下，该视图的控制器的控制器逻辑将与前面的示例不同，但服务步骤仍然相同，因此无需重复，因为服务可以注入到两个控制器中。

这是一个很大的胜利。

示例2：假设您已经按照上面示例1中的描述将控制器和服务之间的代码分开。然后你决定你的数据存储需求已经改变，现在你想更新你的逻辑以保存到不同的数据库系统。现在，不必更换所有的控制器，只需更改服务和一切正常。

这也是一个非常大的胜利。

Answer 2

最佳实践

从我可以看到这是非常好的做法，我假设你使用$scope这里这些服务绑定到一个按钮或类似的东西。使用工厂或服务的想法是创建一些组织良好的可重用代码，然后您可以像控制一样在控制器中实例化。

控制器可能会变得非常复杂，因此将基本功能移到服务中是最好的选择。在你的情况下，你有一个相对简单的控制器，所以你可能不会看到以这种方式编码的好处。但是我向你保证，随着你的代码库的增长，你将被要求像这样编写代码，以保持可读性。

注意

只是作为一个额外的笔记我添加了你可能需要与数据库请求的例子

database > API > service/factory > controller > view 

这将是正确的路该如何走当数据处理从数据库请求一些东西。

Answer 3

是的，你已经做到了这一点。请记住，随着您扩展应用程序的复杂性，您将需要分离范围，（和）分解为组件指令。每个指令都有自己的控制器和模板片段。