如何使用prisma orm在nestjs上创建实体？

Question

我是 Nodejs 后端开发新手

我在使用 Nestjs 和 prisma 进行后端编程时有疑问

大多数与编程相关的书籍、讲座（视频）、人们都说“业务逻辑应该放在实体上”，但 prisma 的模型生成

interface

那么如何在实体上编写业务逻辑呢？这不是课堂

当我使用 typeorm 时，实体就是类。我在实体类上编写业务逻辑

这是我的想法

1

使用 prisma 类型的工具

export default class Tag extends BaseEntity implements tags {
  constructor(data: Tag) {
    super();
    this.id = data.id;
    this.name = data.name;
  }

  id: number;
  name: string;
}

但这不是最好的方法，因为如果当我使用另一个orm时，我需要修改所有实体 我认为这是反模式

我需要后端编程的建议

请分享您对此事的建议

Answer 1

当涉及到使用 NestJS 和 Prisma 构建后端应用程序时，将业务逻辑放置在实体上的概念确实是面向对象编程中常见的最佳实践。虽然 Prisma 为您的模型生成接口而不是类，但您仍然可以有效地将业务逻辑封装在实体中。

您可以考虑以下几种方法：

服务层方法：您可以创建负责处理业务逻辑的服务类，而不是将业务逻辑直接放置在实体本身中。这些服务可以与 Prisma 模型/实体交互以执行 CRUD 操作并根据需要应用业务逻辑。这种方法使您的实体专注于表示数据结构，而业务逻辑则封装在单独的服务类中。

装饰器模式：您可以在NestJS中使用装饰器来实现业务逻辑。装饰器允许您将元数据或附加行为附加到类、方法或属性。例如，您可以创建自定义装饰器以将验证规则、授权检查或其他业务逻辑应用于实体属性或方法。

领域驱动设计（DDD）：DDD 是一种软件开发方法，强调对问题空间的领域进行建模。在 DDD 中，实体封装了与特定领域概念相关的数据和行为。虽然 Prisma 实体可能不是传统的类，但您仍然可以通过围绕领域概念和职责构建代码来应用 DDD 原则。 关于您使用实现和扩展 BaseEntity 的示例，虽然它可能有效，但如果您将来切换到另一个 ORM，它确实可能会出现问题。通常最好避免将应用程序代码与特定 ORM 实现紧密耦合，以保持灵活性。

总而言之，虽然 Prisma 生成的接口可能不是传统意义上的类，但您仍然可以通过使用服务类、装饰器并遵循 DDD 原则来实现关注点分离和业务逻辑封装。通过保持代码模块化和解耦，您将保持后端应用程序的灵活性和可扩展性。