Angular 从一个角度服务到另一个角度服务可以吗？

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

服务

• 授权服务
• 产品服务

组件

• ProductSubmitComponent

ProductService.postProduct

方法对需要

token

参数的API端点执行

POST

请求，该参数可通过

AuthService.get_token（）

方法获得

ProductService

需要在

ProductSubmitComponent

中使用才能提交新产品

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

一,。

ProductService

导入并使用

AuthService

获取令牌，而无需将

ProductSubmitComponent

作为显式参数传递

或

二,。

ProductService.postProduct

方法将

token

作为显式输入参数，请求服务方法时，

ProductSubmitComponent

必须提供该参数作为附加参数

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

---

在另一个中使用一个角度服务与仅从指令/组件而非其他服务严格使用的服务相比，可以吗？

我认为这取决于具体情况。如果您认为要在其他组件中也使用

ProductService.postProduct

方法，那么让

ProductService

导入

AuthService

会更有效

---

据我所知，在另一个服务中使用一个服务并不坏。我很确定你的

AuthService

注入了

Http

服务，这基本上是一样的：）

只要你有一个有意义的、有良好文档记录的依赖注入层次结构，我就会注入一切。从长远来看，这将使测试更容易，因为存在众所周知的依赖关系，您可以一眼看到需要提供或模拟的内容。

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

如果不是，那么组件就不应该关心实现细节——它所希望的只是发布一个产品。因此，如果ProductService能够自己获得令牌，那么它应该很好地做到这一点

还有

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

---

我认为一项服务可以依赖于另一项服务是很好的

---

但是，我个人会考虑使

AuthService

能够更改默认的请求头，这样，如果您不执行跨域请求，它会自动将每个请求上的令牌包含到API中。
保持每个服务松散耦合是最佳编码实践。你的第二条路遇到了它。如果应用第一种方法，则

ProductService

将紧密耦合
这是有道理的。我记得现在读到的文章强调，Auth需要可插拔。本文是针对后端RESTAPI的，但我认为同样的设计模式也适用于客户端应用程序。@PierreDuc的回答是，我接受提前一分钟到达，这与你的回答类似。两个答案都很好。我也有这个问题，读了很多关于它的观点。我能问一下你现在用的是什么吗？为什么？