可以使用另一种角度服务吗？答案

【问题标题】：Is it okay to use one angular service from another?可以使用另一种角度服务吗？
【发布时间】：2016-07-12 08:43:05
【问题描述】：

我有 2 个服务和 1 个组件：

服务

身份验证服务
产品服务

组件

产品提交组件

ProductService.postProduct 方法向需要 token 参数的 API 端点发出 POST 请求，该参数可以通过 AuthService.get_token() 方法获得。 ProductService需要在ProductSubmitComponent中使用才能提交新产品。

有两种方法可以做到这一点

1。 ProductService 导入并使用 AuthService 获取令牌，而 ProductSubmitComponent 不必关心将 token 作为显式参数传递。

或

2。 ProductService.postProduct 方法将token 作为显式输入参数，在请求服务方法时必须由ProductSubmitComponent 作为附加参数提供。

这两种方法都应该有效，但我的困境是，我应该采用哪一种？这个问题实际上归结为：

是否可以在另一个vs服务中使用一个角度服务，这些服务仅从指令/组件而不是其他服务中严格使用？

【问题讨论】：

我也有这个问题，并阅读了很多关于它的意见。请问您现在在用什么？为什么？

标签： angular angular2-services

【解决方案1】：

我认为这取决于情况。如果您认为您也打算在其他组件中使用ProductService.postProduct 方法，那么让ProductService 导入AuthService 会更有效。

据我所知，在另一项服务中使用一项服务并不是一个坏习惯。我很确定你的AuthService 注入了Http 服务，这基本上是一样的:)

【讨论】：

【解决方案2】：

您应该问问自己，是否需要组件中的令牌。

如果不是，那么组件不应该关心实现细节——毕竟它只想发布一个产品。因此，如果 ProductService 可以自己获取令牌，它应该很好地做到这一点。

还有……

...在单元测试中模拟该服务更容易
...到处都没有重复代码

【讨论】：

这是有道理的。我记得现在阅读强调Auth 需要可插拔的文章。这篇文章是针对后端 REST API 的，但我认为同样的设计模式也适用于客户端应用程序。 @PierreDuc 的回答是我早一分钟接受的，这与你的相似。两个不错的答案。

【解决方案3】：

保持每个服务松散耦合是最佳编码实践。你的第二种方式遇到了它。如果您应用第一种方法，那么ProductService 将紧密耦合。

【讨论】：

【解决方案4】：

我认为一个服务可以依赖另一个服务很好。

但是，我个人会考虑让AuthService 能够更改默认请求标头，以便在您不进行跨域请求时，它会自动在对您的 API 的每个请求中包含令牌。

【讨论】：

【解决方案5】：

只要你有一个有意义的、有据可查的依赖注入层次结构，我就会简单地注入所有东西。从长远来看，这将使测试更容易，因为有众所周知的依赖项，您可以一目了然地看到需要提供或模拟的内容。

【讨论】：