我们什么时候应该使用 Angular 服务？

Question

据我所知，我们在组件间和组件内通信的情况下使用服务，其中我们隐藏了多个或复杂的数据结构。我们真的只在持久化数据结构的情况下使用服务吗？那么在哪些情况下我们不应该使用服务呢？

Answer 1

我不同意你的说法。

据我所知，我们在组件间和组件内通信的情况下使用服务，其中我们隐藏了多个或复杂的数据结构。

而不是回答 在我们不应该使用角度服务时？我会回答什么、为什么以及何时使用服务？

`服务`

Service 是一个具有特定用途的类，在 Angular 中，我们使用服务主要是为了三个目的。

1.实现任何独立于任何组件的业务逻辑

.
示例
假设您想从 DOB 计算年龄，现在您提供年份和逻辑可以为您提供年龄，您不需要 HTML 视图来执行此操作，它是独立于组件的

2. 访问共享数据。

在缺乏直接连接的组件之间传递数据时，例如兄弟、孙子等，您应该使用共享服务。您可以使用 RXJSBehaviorSubject或Subject用于跨组件通信。

使用的优点BehaviorSubject或Subject通过纯跨组件交互getters，并setters在您不需要手动触发获取最新的数据的方法。每当数据更改时，注入服务的所有组件都会自动收到通知。

主体和行为主体有什么区别？？？

3. 外部交互

1. 使用Http
--------------------------------------- 访问 REST Web 服务-------------------------------------------------- ------------------------------------------
Angular 中为什么要使用Services

Angular 区分组件以提高模块化和可重用性。 and It's Good Practice to Delegate complex component logic to services

来自Angular Style Guide
将组件中的逻辑限制为视图所需的逻辑。所有其他逻辑都应该委托给服务。

务必将可重用逻辑移至服务并保持组件简单并专注于其预期目的。

为什么？当逻辑被放置在一个服务中并通过一个函数公开时，它可以被多个组件重用。

为什么？在单元测试中可以更轻松地隔离服务中的逻辑，而可以轻松模拟组件中的调用逻辑。

为什么？从组件中删除依赖项并隐藏实现细节。

为什么？保持组件纤薄、修剪和集中。

在 Angular 中使用服务还确保您不会违反 软件开发的DRY和SRP原则。

Providing Services

来自 Angular 文档

你应该提供一个带有@Injectable装饰器的服务，在 中 @NgModule，还是在@Component？这些选择导致最终捆绑包大小、服务范围和服务寿命的差异。

当您在 @Injectable在服务本身装饰器中 CLI 的生产构建所使用的优化工具可以执行摇树，从而删除您的应用程序未使用的服务。摇树导致较小的包大小。

Angular 模块提供程序(@NgModule.providers)在应用程序的根注入器中注册。Angular 可以在它创建的任何类中注入相应的服务。一旦创建，一个服务实例就会在应用程序的生命周期中存在，Angular 会在每个需要它的类中注入这个服务实例。

组件的提供者(@Component.providers)向每个组件实例自己的注入器注册。

Angular 只能在该组件实例或其后代组件实例之一中注入相应的服务。Angular 不能在其他任何地方注入相同的服务实例。

请注意，组件提供的服务可能具有有限的生命周期。组件的每个新实例都有自己的服务实例，当组件实例被销毁时，该服务实例也会被销毁

TLDR

*如果我们希望全局共享依赖项的实例并在整个应用程序中共享 `state`，我们在 `NgModule` 上配置它。

如果我们希望在组件的每个实例及其子组件之间共享一个单独的依赖项实例，我们可以在组件的 `providers` 属性上配置它。*

要获得清晰的图片，请通过Angular 的分层依赖注入系统

好吧，建议始终使用根 AppModule 注册应用程序范围的服务，这使服务成为单例（只要我们的应用程序存在，它就会存在），但这完全取决于用例。

如果服务的唯一目的是在兄弟组件之间共享数据并提供一些帮助程序的方法。向组件提供者注册并使其成为非单例服务。

好处是当 Angular 销毁组件时，Angular 也会销毁服务并释放它占用的内存。@信用

常问问题