本文相关文档：NestJS 中文网
创建模块
nest g命令
我们知道一个模块往往包含controller、module、service等文件，为了方便我们创建这些文件，nest cli提供了一些命令：
生成模块 (nest g mo) 以保持代码井井有条并建立清晰的边界（对相关组件进行分组）
生成控制器 (nest g co) 来定义 CRUD 路由（或 GraphQL 应用的查询/变更）
生成服务 (nest g s) 以实现和隔离业务逻辑
生成一个实体类/接口来表示资源数据形状
生成数据传输对象（或 GraphQL 应用的输入）以定义数据将如何通过网络发送你可以执行nest -h 查看这些命令。
为了生成上述的全部文件，nest还提供了一个命令：
nest g resourcenest g resource 命令不仅生成所有 NestJS 构建块（模块、服务、控制器类），还生成实体类、DTO 类以及测试 (.spec) 文件。
取消生成spec文件
为了避免生成测试文件，你可以传递 --no-spec 标志，如下所示：nest g resource user --no-spec。或者在nest-cli.json中配置：
"generateOptions": {"spec": false}我们在项目根目录下执行nest g res user命令：
我们可以看到生成的资源文件里没有出现spec文件。值得注意的一点是，我们可以在任何路径下执行nest g命令，并在对应位置生成相关文件。但是如果你想让nest-cli.json生效的话，只能在项目根目录执行命令，会在相对于src的路径下生成相应的资源。因为nest cli只会在当前路径下寻找配置文件，可以查看相关实现。 此外，我们还会发现刚才生成的UserModule已经被自动注册到了AppModule中。
样板代码
nest cli已经为我们的user模块创建了样板代码。
样板类和注解
在UserController中，通过构造方法注入了一个USerService的对象。整个UserController使用@Controller('user')进行注解，这个语法叫做装饰器。这个注解表示的是路由路径前缀，UserController中的每个方法对应一个具体的路由，如果这些路由有相同的前缀，我们就可以将这个前缀上升到类本身，这样每个路由只要标注不同的后缀部分即可。
样板方法
方法注解
每个方法都有例如@Post()，@Get(':id')之类的注解，Post、Get本身表示该路由支持的请求方法。括号里是路由，路由可以是静态的路径，也可以带动态的参数。@Get(':id')就表示/user/1之类的路由。此外路由还支持模式匹配，'ab*cd' 路由路径将匹配 abcd、ab_cd、abecd 等。字符 ?、+、* 和 () 可以在路由路径中使用，并且是它们对应的正则表达式的子集。连字符 (-) 和点 (.) 由基于字符串的路径逐字解释。仅 express 支持路由中间的通配符。
我们发现每个方法最终都是返回了一个值，其实框架已经替我们处理响应的状态码，对于get请求是200，post则是201。如果想自定义返回的状态码，可以使用以下注解：
@HttpCode(204)同理，如果想自定义响应的header，也可以：
@Header('Cache-Control', 'none')甚至指定重定向路径：
@Redirect('https://nest.nodejs.cn', 301)样板代码中的方法都是同步的，我们也可以实现异步的，也就是返回类型为Promise<T>。
参数注解
方法参数中也存在着注解，例如findOne(@Param('id') id: string)表示id是路由中的参数值，同理@Query("id")就表示id是路由中的查询参数值。对于get请求，我们使用这两个注解就能获得我们关心的数据。对于post请求，我们关心的数据在请求实体里，需要使用@Body()注解来获取。
载荷转换
用户提交的数据是一个纯 JavaScript 对象，但在我们的DTO架构中，我们希望处理的是具体的类对应的对象。这里我们不能使用接口类型，因为TypeScript 接口在转换过程中被删除。update(@Param('id') id: string, @Body() updateUserDto: UpdateUserDto)表明框架已经将提交的数据转为了UpdateUserDto对象。要启用这个转换，需要使用ValidationPipe。在main.js中添加代码：
// 全局验证app.useGlobalPipes(new ValidationPipe({transform: true,enableDebugMessages: true, // 开发环境disableErrorMessages: false,forbidUnknownValues: false,}),)我们把用于转换或验证输入数据的provider称为管道pipe。provider的作用域可以是指定模板或者全局，这里使用useGlobalPipes设置全局管道。transform:true表示自动将有效负载转换为根据其 DTO 类类型化的对象。当然这种转换也适用于param和query。
数据验证
使用pipe进行数据验证，有如下几种方式：
1.基于schema的验证：
@Post()
async create(@Body() createCatDto: CreateCatDto) {this.catsService.create(createCatDto);
}export class CreateCatDto {name: string;age: number;breed: string;
}
2.基于zod库的Object schema验证
3.类验证器
需要安装class-validator和class-transformer：
npm i --save class-validator class-transformer一旦安装了这些，我们就可以向 CreateCatDto 类添加一些装饰器。在这里，我们看到了这种技术的一个显着优势：CreateCatDto 类仍然是我们的 Post 主体对象的唯一真实来源（而不是必须创建一个单独的验证类）。
import { IsString, IsInt } from 'class-validator';export class CreateCatDto {@IsString()name: string;@IsInt()age: number;@IsString()breed: string;
}
然后我们可以创建一个自定义的pipe，在实现中利用这些注解，对数据进行验证。当然内置的 ValidationPipe已经为我们实现了这一切，方便我们开箱即用。
