模块导出 provider，另一个模块需要 imports 它才能用这些 provider。
但如果这个模块被很多模块依赖了，那每次都要 imports 就很麻烦。
能不能设置成全局的，它导出的 provider 直接可用呢？
Module、Controller、Provider 是由 Nest 创建的，能不能在创建、销毁的时候执行一些逻辑呢？
这节来学习下全局模块和生命周期。
创建一个 nest 项目：
nest new global-and-lifecycle -p npm然后创建两个 CRUD 的模块：
nest g resource aaa --no-spec
nest g resource bbb --no-spec--no-spec 是不生成测试文件
在 AaaModule 里指定 exports 的 provider：
然后在 BbbModule 里 imports：
这样就可以在 BbbModule 内注入 AaaService 了：
把 nest 服务跑起来：
npm run start:dev可以看到 aaaService 生效了：
这是常用的引入 Module 的方式。
但如果这个 AaaModule 被很多地方引用呢？
每个模块都 imports 太麻烦了，这时候就可以把它声明为全局的：
在 AaaModule 上加一个 @Global 的装饰器，然后在 BbbModule 里把 AaaModule 的 imports 去掉。
这样依然是可以注入的：
这就是全局模块。
不过全局模块还是尽量少用，不然注入的很多 provider 都不知道来源，会降低代码的可维护性。
然后是生命周期：
Nest 在启动的时候，会递归解析 Module 依赖，扫描其中的 provider、controller，注入它的依赖。
全部解析完后，会监听网络端口，开始处理请求。
这个过程中，Nest 暴露了一些生命周期方法：
首先，递归初始化模块，会依次调用模块内的 controller、provider 的 onModuleInit 方法，然后再调用 module 的 onModuleInit 方法。
全部初始化完之后，再依次调用模块内的 controller、provider 的 onApplicationBootstrap 方法，然后调用 module 的 onApplicationBootstrap 方法。
然后监听网络端口。
之后 Nest 应用就正常运行了。
这个过程中，onModuleInit、onApplicationBootstrap 都是可以实现的生命周期方法。
来试一下：
再创建两个 Module：
nest g resource ccc --no-spec
nest g resource ddd --no-specnest 提供了这样两个 interface：
在 controller、service、module 里分别实现它：
ddd 模块也是这样。
然后重新跑下服务，会看到这样的日志信息：
这就是 onModuleInit 和 onApplicationBootstrap 生命周期的调用顺序。
应用销毁的时候也同样有生命周期：
先调用每个模块的 controller、provider 的 onModuleDestroy 方法，然后调用 Module 的 onModuleDestroy 方法。
之后再调用每个模块的 controller、provider 的 beforeApplicationShutdown 方法，然后调用 Module 的 beforeApplicationShutdown 方法。
然后停止监听网络端口。
之后调用每个模块的 controller、provider 的 onApplicationShutdown 方法，然后调用 Module 的 onApplicationShutdown 方法。
之后停止进程。
其实是有区别的，可以看下对应的 interface：
beforeApplicationShutdown 是可以拿到 signal 系统信号的，比如 SIGTERM。
这些终止信号是别的进程传过来的，让它做一些销毁的事情，比如用 k8s 管理容器的时候，可以通过这个信号来通知它。
分别给 CccController、CccProvider、CccModule 还有 ddd 模块的那些给加一下：
3s 后调用 app.close() 触发销毁（app.close() 只是触发销毁逻辑，但不会真正退出进程）
生命周期方法是这样的执行顺序：
而且所有的生命周期函数都是支持 async 的。
来看看 @nestjs/typeorm、@nestjs/mongoose 里都是怎么用的：
可以看到，一般都是通过 moduleRef 取出一些 provider 来销毁，比如关闭连接。
这里的 moduleRef 就是当前模块的引用。
来试试：
onApplicationShutdown 的生命周期里，拿到当前模块的引用 moduleRef，调用 get 方法，传入 token，取出对应的 provider 实例，然后调用它的方法。
import { Module, OnModuleInit, OnApplicationBootstrap, OnModuleDestroy, BeforeApplicationShutdown, OnApplicationShutdown } from '@nestjs/common';
import { ModuleRef } from '@nestjs/core';
import { CccService } from './ccc.service';
import { CccController } from './ccc.controller';
@Module({
controllers: [CccController],
providers: [CccService]
})
export class CccModule implements OnModuleInit, OnApplicationBootstrap, OnModuleDestroy, BeforeApplicationShutdown, OnApplicationShutdown {
constructor(private moduleRef: ModuleRef) {}
onModuleDestroy() {
console.log('CccModule onModuleDestroy');
}
beforeApplicationShutdown(signal: string) {
console.log('CccModule beforeApplicationShutdown', signal);
}
onApplicationShutdown() {
const cccService = this.moduleRef.get<CccService>(CccService);
console.log('--------------------------', cccService.findAll());
console.log('CccModule onApplicationShutdown');
}
onModuleInit() {
console.log('CccModule OnModuleInit');
}
onApplicationBootstrap() {
console.log('CccModule onApplicationBootstrap');
}
}这就是 onApplicationShutdown 生命周期的常见用法。
这节学习了全局模块和生命周期。
模块可以通过 @Global 声明为全局的，这样它 exports 的 provider 就可以在各处使用了，不需要 imports。
provider、controller、module 都支持启动和销毁的生命周期函数，这些生命周期函数都支持 async 的方式。
可以在其中做一些初始化、销毁的逻辑，比如 onApplicationShutdown 里通过 moduleRef.get 取出一些 provider，执行关闭连接等销毁逻辑。
全局模块、生命周期、moduleRef 都是 Nest 很常用的功能。
前面讲过，Provider 是可以通过 useFactory 动态产生的，那 Module 可不可以呢？
自然是可以的，这节就来学下动态模块 Dynamic Module。
新建一个项目：
nest new dynamic-module -p npm执行
nest g resource bbb创建一个实现了 CRUD 的模块：
然后执行：
npm run start:dev浏览器访问下，可以看到 bbb 模块生效了：
这个模块是静态的，也就是它的内容是固定不变的，每次 import 都是一样：
有的时候希望 import 的时候给这个模块传一些参数，动态生成模块的内容，怎么办呢？
这时候就需要 Dynamic Module 了：
import { DynamicModule, Module } from '@nestjs/common';
import { BbbService } from './bbb.service';
import { BbbController } from './bbb.controller';
@Module({})
export class BbbModule {
static register(options: Record<string, any>): DynamicModule {
return {
module: BbbModule,
controllers: [BbbController],
providers: [
{
provide: 'CONFIG_OPTIONS',
useValue: options,
},
BbbService,
],
exports: []
};
}
}给 BbbModule 加一个 register 的静态方法，返回模块定义的对象。
和在装饰器里定义的时候的区别，只是多了一个 module 属性：
而且还可以把参数传入的 options 对象作为一个新的 provider。
import 的时候就得这样用了，通过 register 方法传入参数，返回值就是模块定义：
改成这样之后，再跑一下：
依然是正常的。
而且这时候把传入的 options 通过 useValue 创建了个 provider，这样模块内部就可以注入它了。
我在 BbbController 里面通过 token 注入这个 provider，打印下它的值。
改一下 register 的参数：
浏览器再访问下，可以看到控制台打印了 config 对象：
这样就可以在 import 一个模块的时候，传入参数，然后动态生成模块的内容。
这就是 Dynamic Module。
这里的 register 方法其实叫啥都行，但 nest 约定了 3 种方法名：
约定它们分别用来做不同的事情：
register：用一次模块传一次配置，比如这次调用是 BbbModule.register({aaa:1})，下一次就是 BbbModule.register({aaa:2}) 了
forRoot：配置一次模块用多次，比如 XxxModule.forRoot({}) 一次，之后就一直用这个 Module，一般在 AppModule 里 import
forFeature：用了 forRoot 固定了整体模块，用于局部的时候，可能需要再传一些配置，比如用 forRoot 指定了数据库连接信息，再用 forFeature 指定某个模块访问哪个数据库和表。
光这么说可能不够直观，看一个真实的动态模块就懂了。
比如 @nestjs/typeorm 的动态模块：
forRoot 传入配置，动态产生 provider 和 exports，返回模块定义。
而且还有 forRootAsync：
区别就是可以用 async 的 useFactory 动态产生 provider，比如异步请求别的服务拿到配置返回，作为 options。
forFeature 则是传入局部的一些配置，来动态产生局部用的模块：
typeorm 的模块用起来是这样的：
在 AppModule 里 import 通过 forRoot 动态产生的模块，在具体的业务 Module 里，通过 forFeature 传入具体实体类的配置。
其实 forRoot、forFeature、register 有区别么？
本质上没区别，只是约定了它们使用上的一些区别。
此外，Nest 还提供了另一种方式来创建动态模块：
再生成一个新模块：
nest g module ccc然后生成个 controller：
nest g controller ccc --no-spec这次不手动写 register、registerAsync 等方法了，用 builder 来生成。
新建一个 ccc.module-definition.ts 文件：
import { ConfigurableModuleBuilder } from "@nestjs/common";
export interface CccModuleOptions {
aaa: number;
bbb: string;
}
export const { ConfigurableModuleClass, MODULE_OPTIONS_TOKEN } =
new ConfigurableModuleBuilder<CccModuleOptions>().build();用 ConfigurableModuleBuilder 生成一个 class，这个 class 里就带了 register、registerAsync 方法。
返回的 ConfigurableModuleClass、MODULE_OPTIONS_TOKEN 分别是生成的 class 、options 对象的 token。
然后 Module 继承它：
这样这个 CccModule 就已经有了 register 和 registerAsync 方法了：
不用自己定义了，省事了不少。
传入 options：
那现在如何在 Module 内注入这个 options 呢？
记得 build class 的时候返回了一个 token 么？
就用这个注入：
import { Controller, Get, Inject } from '@nestjs/common';
import { MODULE_OPTIONS_TOKEN, CccModuleOptions } from './ccc.module-definition';
@Controller('ccc')
export class CccController {
@Inject(MODULE_OPTIONS_TOKEN)
private options: CccModuleOptions;
@Get('')
hello() {
return this.options;
}
}浏览器访问下：
可以看到拿到了 options 对象。
当然，options 对象不是这么用的，一般是用来做配置，内部的 provider 基于它来做一些设置，这里只是演示。
你还可以用 registerAsync 方法，用 useFactory 动态创建 options 对象：
前面不是说还可以用 forRoot、forFeature 这样的方法么？
那用 builder 的方式如何生成这样的 class 呢？
调用 setClassMethodName 设置下就好了：
如果我还想根据传入的参数决定是否设置为全局模块呢？
那就要这样写了：
import { ConfigurableModuleBuilder } from "@nestjs/common";
export interface CccModuleOptions {
aaa: number;
bbb: string;
}
export const { ConfigurableModuleClass, MODULE_OPTIONS_TOKEN } =
new ConfigurableModuleBuilder<CccModuleOptions>().setClassMethodName('register').setExtras({
isGlobal: true
}, (definition, extras) => ({
...definition,
global: extras.isGlobal,
})).build();
setExtras 第一个参数是给 options 扩展啥 extras 属性，第二个参数是收到 extras 属性之后如何修改模块定义。
定义了 isGlobal 的 option，收到它之后给模块定义加上个 global。
这时候你就会发现 register 的 options 多了 isGlobal：
这样创建的就是全局的模块。
不过这样还有个问题：
options 那里多了 isGlobal 属性，但是类型定义这里还没有呀。
因为用的是这个类型：
最好是用 builder 返回的类型：
这样就有了：
而这个 ASYNC_OPTIONS_TYPE 是 async 方式创建模块的 option 类型：
回过头来看一下这个 ConfigurableModuleBuilder，它只是对定义 register、registerAsync 的过程做了封装，传参数就可以生成对应的 class，简便了不少。
如果你觉得这种 builder 的方式更麻烦，那直接用第一种方式也可以。
Module 可以传入 options 动态产生，这叫做动态 Module，你还可以把传入的 options 作为 provider 注入到别的对象里。
建议的动态产生 Module 的方法名有 register、forRoot、forFeature 3种。
register：用一次注册一次
forRoot：只注册一次，用多次，一般在 AppModule 引入
forFeature：用了 forRoot 之后，用 forFeature 传入局部配置，一般在具体模块里 imports
并且这些方法都可以写 xxxAsync 版本，也就是传入 useFactory 等 option，内部注册异步 provider。
这个过程也可以用 ConfigurableModuleBuilder 来生成。通过 setClassMethodName 设置方法名，通过 setExtras 设置额外的 options 处理逻辑。
并且返回的 class 都有 xxxAsync 的版本。
这就是动态模块的定义方式，后面用到 typeorm、mongoose 等模块会大量见到这种模块。