【发布时间】:2020-04-20 04:02:27
【问题描述】:
我想开始使用 NestJs 创建 REST API,但我不确定如何设置可扩展层通信对象。
所以从关于如何get started 的文档中,我想出了一个UsersController 处理HTTP 请求和响应,一个UsersService 处理控制器和数据库访问器之间的逻辑以及UsersRepository负责数据库管理。
我使用 NestJs 提供的TypeORM package,所以我的数据库模型是
@Entity('User')
export class UserEntity extends BaseEntity {
@PrimaryGeneratedColumn('uuid')
id: string;
@Column({ unique: true })
username: string;
@Column()
passwordHash: string;
@Column()
passwordSalt: string;
}
但您可能知道此模型必须映射到其他模型,反之亦然,因为您不想将密码信息发送回客户端。我将尝试用一个简单的例子来描述我的 API 流程:
控制器
首先我有一个GET /users/:id 和POST /users 的控制器端点。
@Get(':id')
findById(@Param() findByIdParamsDTO: FindByIdParamsDTO): Promise<UserDTO> {
// find user by id and return it
}
@Post()
create(@Body() createUserBodyDTO: CreateUserBodyDTO): Promise<UserDTO> {
// create a new user and return it
}
我设置了DTOs 并想先验证请求。我使用 NestJs 提供的 class-validator 包并创建了一个名为 RequestDTOs 的文件夹。通过 id 查找某些内容或通过 url 参数通过 id 删除某些内容是可重复使用的,因此我可以将其放入共享文件夹中,用于其他资源(如组、文档等)。
export class IdParamsDTO {
@IsUUID()
id: string;
}
POST 请求是用户特定的
export class CreateUserBodyDTO {
@IsString()
@IsNotEmpty()
username: string;
@IsString()
@IsNotEmpty()
password: string;
}
现在控制器输入在执行业务逻辑之前得到验证。对于回复,我创建了一个名为 ResponseDTOs 的文件夹,但目前它只包含没有密码信息的数据库用户
export interface UserDTO {
id: string;
username: string;
}
服务
服务需要来自参数和正文的捆绑信息。
public async findById(findByIdBO: FindByIdBO): Promise<UserBO> {
// ...
}
public async create(createBO: CreateBO): Promise<UserBO> {
// ...
}
GET 请求只需要 ID,但创建 BO 可能会更好,因为您可能希望稍后从字符串 ID 切换为整数。 “按 id 查找”BO 是可重复使用的,我将其移至共享目录
export interface IdBO {
id: string;
}
为了创建用户,我创建了文件夹 RequestBOs
export interface CreateBO {
username: string;
password: string;
}
现在对于 ResponseBOs,结果将是
export interface UserBO {
id: string;
username: string;
}
您会注意到这与 UserDTO 相同。所以其中一个似乎是多余的?
存储库
最后我为存储库设置了DAOs。我可以使用自动生成的用户存储库并处理我上面提到的数据库模型。但是我必须在我的服务业务逻辑中处理它。创建用户时,我必须在服务中执行此操作,并且只能从存储库中调用 usermodel.save 函数。
否则我可以创建 RequestDAO
共享的..
export interface IdDAO {
id: string;
}
还有 POST DAO
export interface CreateDAO {
username: string;
password: string;
}
这样我可以在我的存储库中创建一个数据库用户并使用 ResponseDAOs 映射数据库响应,但这始终是没有密码信息的整个数据库用户。似乎又产生了很大的开销。
我想知道我使用 3 个请求和 3 个响应接口的方法是否太多并且可以简化。但我想保留一个灵活的层,因为我认为这些层应该是高度独立的......另一方面,那里会有大量的模型。
提前致谢!
【问题讨论】:
-
老实说,我相信 3 个请求/响应 dto 是可行的方法,原因如下:理论上,如果您有一个“UsersModule”,该模块会将“用户”模型返回给应用程序的其余部分但是该模块如何与数据库对话应该与应用程序的其余部分无关。它将定义它自己的 dto 用于与数据库的通信。这样,如果您决定交换存储用户的数据库,应用程序的其余部分将不受影响。这创建了正确的关注点分离,并且是一个很好的模式,尽管模型/dto 有“重复”。
-
嗯,是的,我只是在考虑它,因为我只能在需要隐藏敏感数据(密码)的地方对用户进行成像。例如,组可以作为数据库模型返回...
标签: typescript nestjs clean-architecture onion-architecture