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

查看:141
本文介绍了什么时候应该使用角度服务?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

据我了解,我们在内部和内部组件通信的情况下使用服务,其中我们隐藏了多个或复杂的数据结构.我们仅在持久性数据结构的情况下才使用服务吗?那么在什么情况下我们不应该使用服务呢?

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?

推荐答案

我希望与您的声明有所不同.

I Would beg to differ with the statement you made.

据我了解,我们在内部和内部使用服务 组件通信,其中我们隐藏了多个或复杂的数据 结构.

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

何时不应该使用角度服务而不是回答?我会回答什么,为什么以及何时使用服务?

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

Services

服务是具有特定目的的类,在Angular中,我们主要将服务用于三个目的.

Services

A Service is a class with a specific purpose, and In Angular, we use services mainly for three purposes.

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.

getterssetters相比,使用BehaviorSubjectSubject进行跨组件交互的优势是您不需要手动触发获取最新数据的方法.每当数据更改时,将自动通知所有注入服务的组件.

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.

Subject和BehaviorSubject有什么区别?

3.外部互动

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

Angular将组件与服务区分开来,以提高模块化和可重用性. and It's Good Practice to Delegate complex component logic to services

What is the difference between Subject and BehaviorSubject???

3. External Interactions

1.Accessing REST Web Services Using Http
-----------------------------------------------------------------------------------------------------------------------------------
Why use Services in Angular

Angular distinguishes components from services in order to increase modularity and reusability. and It's Good Practice to Delegate complex component logic to services

摘自 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 的软件原理开发.

Providing Services

FROM Angular Docs

Providing Services

FROM Angular Docs

您是否应该在@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 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

如果我们希望全局共享一个依赖项实例,并在整个应用程序中共享state,则可以在NgModule上对其进行配置.

如果我们希望在组件的每个实例之间共享一个依赖项的单独实例,并且它是其子级,则可以在组件的providers属性上对其进行配置.

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.


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


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 child’s components and to provide a couple of helper’s methods.

向组件提供者注册并使其成为非单身 服务.

Register it with component providers and make it a non-singleton service.

好处是,当Angular销毁组件时,Angular也会销毁服务并释放其占用的内存. @ 常见问题解答

FAQ

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

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆