Question

我发现了许多嵌套“示例”应用程序的示例，但是每个应用程序似乎对设计模式都有不同的看法。我目前对与TypeORM结合时对象准备工作应该在解析器和服务之间进行的位置感兴趣。

例如：

comment.resolver.ts：

/********************
 * @MUTATION
 *********************/

/**
 *
 * @param payload
 * @param args
 */
@Mutation('createComment')
async create(@CurrentUser() payload: JwtPayload, @Args('input') args: CreateCommentInputDto): Promise < CommentEntity > {
  const currentUser = await this.userService.getCurrentUser(payload);
  const initComment = new CommentEntity();
  const newComment: CommentEntity = {
    ...args,
    createdBy: currentUser,
    createdDate: new Date(),
    modifiedDate: new Date(),
    ...initComment,
  };
  const createdComment = await this.commentService.create(newComment);
  pubSub.publish('CommentCreated', {
    CommentCreated: createdComment
  });
  return createdComment;
}

comment.service.ts：

/**
 *
 * @param comment
 */
async create(comment: CommentEntity): Promise < CommentEntity > {
  return await this.CommentsRepository.save(comment);
}

即

创建新的空评论实体
添加查询未提供的字段值
使用传播运算符将它们全部组合在一起
将它们全部传递到评论服务以通过TypeORM存储库保存

原因是评论服务只接受并保存格式正确的实体。也许将来，我将需要准备以不同方式创建的注释，以便在新的变异中进行定义。

这是反模式吗？我是否应该将该对象的创建/合并/格式化转移到服务中，并使解析器方法尽可能轻巧？

如果是这样，其背后的逻辑是什么？

Answer 1

您应该检查TypeOrm提供的preload项目提供的Repository方法。它允许批量更改现有实体或新实体上的更改，这应该是您想要的。

我认为TypeOrm非常不受限制，您可以自由选择如何在实体上组织突变。不过，我仍然认为“预加载”存储库模式是一种安全的模式，因为您始终希望首先从数据库中获取与您建议的更改相对应的价值，然后将更改分批存储到实体中，然后再保存。这样可以降低您在实体上获得冲突值或获得双倍值等的机会。

您可以将数据库视为git存储库，先获取，然后将本地更改基于远程head值，然后提交并推送更改。

NestJS + TypORM设计模式：解析程序与服务

1 个答案: