Advanced Features

📄️ 过滤器

MikroORM 能够预定义过滤条件并将这些过滤器附加到给定的实体。然后，应用可以在运行时决定是否应启用某些过滤器以及它们的参数值应该是什么。过滤器可以像数据库视图一样使用，但它们在应用内部参数化。

📄️ 部署

在底层，MikroORM 使用 ts-morph 读取所有实体的 TypeScript 源文件，以便能够检测所有类型。多亏了这一点，定义类型就足以进行运行时验证。

📄️ 结果缓存

MikroORM 有一个简单的结果缓存机制。它与 EntityManager 的那些方法一起工作：find()、findOne()、findAndCount()、findOneOrFail()、count()，以及 QueryBuilder 结果方法（包括 execute）。

📄️ 传播

默认情况下，MikroORM 会将对双向关系一侧所做的所有更改传播到另一侧，使它们保持同步。这适用于所有关系，包括 M1。作为发现过程的一部分，所有 M1 属性都被重新定义为 getter/setter。

n+1 问题是在一个查询中请求多种类型的数据，但需要 n 个请求而不是一个。这通常在数据嵌套时遇到，例如如果你请求作者及其书籍的名称。这是 GraphQL API 固有的问题，可以通过将多个请求批量合并为一个请求来解决。这可以通过数据加载器库自动执行，该库将合并在单个执行框架（事件循环的单个滴答）内发生的所有单独加载，然后使用所有请求的键调用批处理函数。这意味着为每个数据库调用编写一个批量加载函数，将多个查询聚合为一个查询，并过滤结果以将它们重新分配给原始查询。幸运的是，MikroORM 有大量元数据可以透明地自动化此过程，因此你不必编写自己的批量加载函数。

📄️ 序列化

默认情况下，ORM 将在发现期间在所有实体原型上定义 toJSON 方法。这意味着当你尝试通过 JSON.stringify() 序列化实体时，ORM 序列化将自动启动。默认实现使用 EntityTransformer.toObject() 方法，将实体实例转换为 POJO。在此过程中，ORM 特定构造（如 Reference 或 Collection 封装器）将转换为其底层值。

📄️ 事件和钩子

有两种方法可以挂接到实体的生命周期：

📄️ 复合主键

版本 3.5 中添加了对复合键的支持

📄️ 自定义类型

你可以通过扩展 Type 抽象类来定义自定义类型。它有几种可选方法：

📄️ 虚拟实体

虚拟实体不代表任何数据库表。相反，它们动态解析为 SQL 查询（或 MongoDB 中的聚合），允许将任何类型的结果映射到实体上。此类实体用于读取目的，它们没有主键，因此无法跟踪更改。在某种程度上，它们类似于（当前不支持的）数据库视图，你可以使用它们来代理你的原生视图。

📄️ 可嵌入项

版本 4.0 中添加了对可嵌入项的支持

📄️ 通过 EntitySchema 定义实体

使用 EntitySchema 助手，我们以编程方式定义模式。

📄️ 使用 JSON 属性

定义 JSON 属性

📄️ 元数据提供程序

作为实体发现过程的一部分，MikroORM 使用所谓的 MetadataProvider 来获取有关我们实体属性的必要类型信息。

📄️ 元数据缓存

在 v4 及更高版本中，我们需要明确安装 @mikro-orm/reflection 才能使用 TsMorphMetadataProvider。

📄️ 模式生成器

SchemaGenerator 可能会损害你的数据库。它将删除或更改表、索引、序列等。请在开发中谨慎使用此工具，而不是在生产服务器上使用。它旨在帮助你开发数据库模式，但不是在生产中将模式从 A 迁移到 B。一种安全的方法是生成开发服务器上的 SQL 并将其保存到在生产服务器上手动执行的 SQL 迁移文件中。