我们什么时候应该使用 Angular 服务? [英] when we should use angular service?

问题描述

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

From what I understand, we use services in the case of inter and intra components communication where we hide multiple or complex data structures. Is it true we only use services in the case of persistent data structure? So what are cases we should not use services?

推荐答案

我不同意你的说法.

据我所知，我们在inter和intra的情况下使用服务我们隐藏多个或复杂数据的组件通信结构.

From what I understand, we use services in the case of inter and intra components communication where we hide multiple or complex data structures.

而不是回答什么时候我们不应该使用 Angular 服务?我会回答什么，为什么以及何时使用服务?

Instead of answering when we should not use angular service? I would answer what, why and when to use services?

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

.
示例
假设您想从 DOB 计算年龄，现在您提供年份并且逻辑可以给你年龄你不需要 HTML 视图来做到这一点,它是组件独立的

.
Example
Assume you want to calculate the age from DOB, Now you provide the year and The logic can give you age you would not need an HTML view to do that ,it is component Independent

2.访问共享数据.

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

2. Access to Shared Data.

When passing data between components that lack a direct connection, such as siblings, grandchildren, etc, you should use a shared service. You could either use RXJS BehaviorSubject or Subject for cross component communication.

使用 BehaviorSubject 或 Subject 进行跨组件交互的优势比普通的 getter 和 setter 是您不需要手动触发获取最新数据的方法.每当数据发生更改时，所有注入服务的组件都会自动收到通知.

The advantage of using BehaviorSubject or a Subject for cross-component interaction over plain getters and setters is you don't need to manually trigger a method to fetch latest data. Whenever the data is changed all the components where service is injected are automatically notified.

主题和行为主题有什么区别???

<强>3.外部互动

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

Angular 将组件与服务区分开来，以增加模块化和可重用性.以及委托复杂组件的良好做法服务逻辑

来自 Angular 样式指南
将组件中的逻辑限制为仅视图所需的.所有其他逻辑都应委托给服务.

From Angular Style Guide
Do limit logic in a component to only that required for the view. All other logic should be delegated to services.

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

Do move reusable logic to services and keep components simple and focused on their intended purpose.

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

Why? Logic may be reused by multiple components when placed within a service and exposed via a function.

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

Why? Logic in a service can more easily be isolated in a unit test, while the calling logic in the component can be easily mocked.

为什么?删除依赖项并隐藏实现细节组件.

Why? Removes dependencies and hides implementation details from the component.

为什么?使组件保持苗条、修剪和集中.

Why? Keeps the component slim, trim, and focused.

在 Angular 中使用服务还可以确保您没有违反 DRY 和 SRP 软件原则

提供服务

来自 Angular 文档

您是否应该提供带有 @Injectable 装饰器的服务，在@NgModule，还是在 @Component 中?选择导致差异最终的捆绑包大小、服务范围和服务生命周期.

Should you provide a service with an @Injectable decorator, in an @NgModule, or within an @Component? The choices lead to differences in the final bundle size, service scope, and service lifetime.

当你在 @Injectable 装饰器中注册提供者时服务本身，优化工具，例如 CLI 使用的那些生产构建可以执行摇树，从而删除服务您的应用程序未使用的那些.摇树导致较小的捆绑尺寸.

When you register providers in the @Injectable decorator of the service itself, optimization tools such as those used by the CLI's production builds can perform tree shaking, which removes services that aren't used by your app. Tree shaking results in smaller bundle sizes.

Angular 模块提供者 (@NgModule.providers) 注册到应用程序的根注入器.Angular 可以注入对应的它创建的任何类中的服务.一旦创建，一个服务实例为应用程序的生命而生，Angular 注入了这一服务实例在每个需要它的类中.

Angular module providers (@NgModule.providers) are registered with the application's root injector. Angular can inject the corresponding services in any class it creates. Once created, a service instance lives for the life of the app and Angular injects this one service instance in every class that needs it.

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

A component's providers (@Component.providers) are registered with each component instance's own injector.

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

Angular can only inject the corresponding services in that component instance or one of its descendant component instances. Angular cannot inject the same service instance anywhere else.

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

Note that a component-provided service may have a limited lifetime. Each new instance of the component gets its own instance of the service and, when the component instance is destroyed, so is that service instance

TLDR

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

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

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

TLDR

*if we want an instance of a dependency to be shared globally and share `state` across the application we configure it on the `NgModule`.

If we want a separate instance of a dependency to be shared across each instance of a component and it’s children we configure it on the components `providers` property.*

To get a Clear Picture Go through Angular's Hierarchical Dependency Injection system

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

Well, it's recommended to Always register application-wide services with the root AppModule which makes a service singleton(it will live as long as our application lives) but it entirely depends upon the use case.

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

If the sole purpose of the service is to share data between sibling components and to provide a couple of helper’s methods.Register it with component providers and make it a non-singleton service.

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

常见问题解答

这篇关于我们什么时候应该使用 Angular 服务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！