您应该使用 Prisma ORM 吗?
Prisma ORM 是一种新型 ORM,像任何其他工具一样,它也有自己的权衡。此页面解释了 Prisma ORM 何时是一个不错的选择,并为其他情况提供了替代方案。
如果您属于以下情况,Prisma ORM 很可能是一个不错的选择 ...
... 您正在构建一个与数据库对话的服务器端应用程序
这是 Prisma ORM 的主要用例。服务器端应用程序通常是 API 服务器,它们通过 REST、GraphQL 或 gRPC 等技术公开数据操作。它们通常构建为微服务或单体应用,并通过长期运行的服务器或无服务器函数进行部署。Prisma ORM 非常适合所有这些应用程序和部署模型。
请参阅 Prisma ORM 支持的数据库(关系型、NoSQL 和 NewSQL)的完整列表。
... 您关心生产力和开发者体验
生产力和开发者体验是我们构建工具的核心。我们致力于为手动执行时复杂、容易出错且耗时的任务构建开发者友好的抽象。
无论您是 SQL 新手还是资深人士,Prisma ORM 都将为您最常见的数据库工作流程提供显着的生产力提升。
以下是我们在设计和构建工具时应用的一些指导原则和通用实践
- 让正确的事情变得容易
- 成功之坑
- 在可能的情况下提供智能自动完成
- 构建强大的编辑器扩展程序(例如,用于 VS Code)
- 尽最大努力实现完全的类型安全
... 您正在团队中工作
Prisma ORM 在协作环境中尤其出色。
声明式 Prisma schema 提供了数据库当前状态的概述,每个人都容易理解。与传统的工作流程相比,这是一个重大改进,在传统的工作流程中,开发人员必须深入研究迁移文件才能理解当前的表结构。
Prisma Client 的极简 API 表面使开发人员能够快速上手,而无需太多的学习开销,因此团队中新开发人员的入职变得更加顺畅。
Prisma Migrate 工作流程的设计方式涵盖了协作环境中的数据库模式更改。从初始模式创建到将模式更改部署到生产环境以及解决由并行修改引起的冲突,Prisma Migrate 都能满足您的需求。
... 您想要一个整体覆盖数据库工作流程的工具
Prisma ORM 不仅仅是“另一个 ORM”。我们正在构建一个数据库工具包,涵盖与数据库交互的应用程序开发人员的日常工作流程。一些例子是
- 查询(使用 Prisma Client)
- 数据建模(在 Prisma schema 中)
- 迁移(使用 Prisma Migrate)
- 原型设计(通过
prisma db push
) - 种子填充(通过
prisma db seed
) - 可视化查看和编辑(使用 Prisma Studio)
... 您重视类型安全
Prisma ORM 是 TypeScript 生态系统中唯一完全类型安全的 ORM。生成的 Prisma Client 确保类型化的查询结果,即使对于部分查询和关系也是如此。您可以在 与 TypeORM 的类型安全比较中了解更多关于此信息。
... 您想要编写原始的、类型安全的 SQL
除了直观的、更高级别的查询 API 之外,Prisma ORM 还为您提供了一种 编写具有完全类型安全的原始 SQL 的方法。
... 您想要一个具有透明开发流程、适当维护和支持的 ORM
Prisma ORM 的开源工具的开发是公开进行的。其中大部分直接在 GitHub 上的主 prisma/prisma
仓库中进行
- 我们仓库中的 issue 和 PR 会被分类和优先处理(通常在 1-2 天内)
- 每三周发布新的 版本,其中包含新功能和改进
- 我们有一个专门的支持团队,负责回复 GitHub Discussions 中的问题
... 您想成为一个很棒的社区的一份子
Prisma 拥有一个活跃的社区,您可以在 Discord 上找到它。我们还定期举办 Meetups、会议和其他以开发者为中心的活动。加入我们吧!
如果您属于以下情况,Prisma ORM 很可能不是一个不错的选择 ...
... 您需要完全控制所有数据库查询
Prisma ORM 是一种抽象。因此,Prisma ORM 的一个内在权衡是控制量的减少,以换取更高的生产力。这意味着,在某些情况下,Prisma Client API 的功能可能不如您使用纯 SQL 获得的功能多。
如果您的应用程序对 Prisma ORM 未提供的数据库查询有要求,并且变通方法过于昂贵,那么您最好使用一种允许您使用纯 SQL 完全控制数据库操作的工具。
注意:如果您可以解决某个限制,但仍然希望看到 Prisma ORM 处理这种情况的方式有所改进,我们鼓励您在 GitHub 上创建一个 功能请求,以便我们的产品和工程团队可以调查它。
替代方案:SQL 驱动程序(例如 node-postgres
, mysql
, sqlite3
, ...)
... 您不想为您的后端编写任何代码
如果您不想为您的后端编写任何代码,只想能够开箱即用地生成您的 API 服务器和数据库,那么您可能更愿意为您的项目选择后端即服务 (BaaS)。
使用 BaaS,您通常可以通过高级 API(例如 GraphQL SDL)或可视化编辑器配置您的数据模型。基于此数据模型,BaaS 会为您生成 CRUD API 并配置数据库。通过这种设置,您通常无法控制 API 服务器和数据库运行的基础架构。
使用 Prisma ORM,您正在使用 Node.js 或 TypeScript 自己构建后端。这意味着与使用 BaaS 相比,您将需要做更多编码工作。这种方法的好处是,您可以完全灵活地构建、部署、扩展和维护您的后端,并且在堆栈的关键部分不依赖于第三方软件。
替代方案:AWS AppSync, 8base, Nhost, Supabase, Firebase, Amplication
... 您想要一个无需编写任何代码的 CRUD GraphQL API
虽然像 nexus-plugin-prisma
和 typegraphql-prisma
这样的工具允许您在 GraphQL API 中为您的 Prisma ORM 模型快速生成 CRUD 操作,但这些方法仍然需要您手动设置您的 GraphQL 服务器,并做一些工作来为您的 Prisma schema 中定义的模型公开 GraphQL 查询和 mutation。
如果您想要为您的数据库开箱即用地获得一个 GraphQL 端点,那么其他工具可能更适合您的用例。
替代方案:Hasura, Postgraphile