十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
angular官方文档单例服务的说明
创新互联成立于2013年,我们提供高端网站建设、成都网站制作、成都网站设计、网站定制、营销型网站、成都小程序开发、微信公众号开发、网站推广服务,提供专业营销思路、内容策划、视觉设计、程序开发来完成项目落地,为白乌鱼企业提供源源不断的流量和订单咨询。
单例模式就不要说了,懂点设计模式的都懂得,真有不明白的自行百度。
(解释下angular的命名,angular就是angular2+,angular1叫angularjs,至于angular2,3,4,5,6只是angular的版本,通称angular,希望小伙伴不要叫错了)
单例模式如何在angular的服务中使用呢,angular的官方文档中有这么一段话:
单例服务
服务在每个注入器的范围内是单例的。 在任何一个注入器中,最多只会有同一个服务的一个实例。
这里只有一个根注入器,而 UserService 就是在该注入器中注册的。 所以,在整个应用中只能有一个 UserService 实例,每个要求注入 UserService 的类都会得到这个服务实例。
不过,Angular DI 是一个 多级注入系统,这意味着各级注入器都可以创建它们自己的服务实例。 Angular 总会创建多级注入器。
笼统,并不知道依赖注入服务单例模式怎么用,要想弄明白很简单,简单的写个例子实验一下就可以了,下面我会给大家说一下我的实验总结,帮助小伙伴节约一些这种乏味的探索时间。
实验样例代码
服务代码
import { Injectable } from '@angular/core'; @Injectable( //{providedIn: 'root'} ) export class SingletonServiveTestService { private _name = "primaryName"; constructor() { } setName (name){ this._name = name; } getName(){ return this._name; } }
小伙伴可能会说了,这TM怎么会是单例模式。小伙伴不要激动,我也是这么想的,怎么TM怎么会是单例。不过在angular的依赖注入中,有几种写法确实会使这种代码以单例模式的方式运行。
解释下{providedIn: 'root'},一开始认为只要传入这个对象,让服务以root的方式提供给子module,子组件,然后这个服务就是单例的,后台发现,这个对象和单例没有半毛钱关系,它只是app.module中引入服务的另一种写法,除了这个用处,没有别的用处,所以下文中我们就不说添加和不添加{providedIn: 'root'}的情况了
注入代码
注入分为Module.providers和Component.providers两种;实验的module是实现懒加载的。
上面代码的测试结果(module都是懒加载的)
这三个结果已经代表各种情况了,如果小伙伴还想知道其他一些情况的下的结果,小伙伴可以自己动手写个例子,或者给我留言
单例不都通过静态属性来实现的吗?
我认为单例就是实现属性方法的保持一个实例,而angular中想用到单例多是实现一些数据整个项目通用,按照设计模式上讲上面和下面的代码都不是标准的单例模式的写法,但是在实际使用中确实是达到了单例模式的目的,上吗的有angular的官方文档做背书,所以我就写了上吗那种在angular中可以是单例模式,至于下面这中我就叫静态属性单一模式,ts静态属性被编译成正常的js,就是构造函数上的属性而已,概念高大上,原理矮小low。
import { Injectable } from '@angular/core'; @Injectable() export class SingletonServiveTestService { private static _name = "primaryName"; constructor() { } setName (name){ SingletonServiveTestService._name = name; } getName(){ return SingletonServiveTestService._name; } }
这个实验着在各种情况下都能表现 单例 特征
这种方法万金油,单例就用这中不久ok了,小伙伴写代码要考究,莫要粗放。结合上面代码代码的单例实现根据具体使用场景来选择用那种方式。
真正严格的用单例模式的话是用不上angular服务的依赖注入的这套机制的。至于要不要使用单例抛掉依赖注入,看业务场景了。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持创新互联。