NestJS 与抽象类集合的关系答案

【问题标题】：NestJS relation to collection of abstract classNestJS 与抽象类集合的关系
【发布时间】：2019-12-01 16:06:08
【问题描述】：

我正在尝试使用 TypeORM 为下一个逻辑对象模型实现数据持久层：

这个想法是Provider 拥有AbstractResources 的集合，这些集合描述了公共信息并持有对此AbstractResources 实例的可用Options 的引用。

存储在resources 集合中的对象的确切数据类型继承自AbstractResource：Scooter 和Bicycle。

“具体表继承”方式（使用带有@Entity 子类的抽象类）不起作用，因为 Option 实体针对的是无效实体且没有数据库表的 AbstractResource 实体。
“单表继承”方式也不能开箱即用，因为当我将 Provider 及其 AbstractResoruce 集合作为信号请求持久化时，我在类型鉴别器列中看到 AbstractEntitiy。我尝试在持久化之前将具有此名称的属性显式添加到具有正确值的子类中，但是在持久化期间此值会覆盖。
```
@Entity()
@TableInheritance({
    column: { name: 'discriminator', type: 'varchar' }
})
export abstract class Resource{
```
“最有效”的方式是“单表继承”，但每个子实体类型在 Provider 内都有独立的集合。这样持久性可以正常工作，从AbstractResource 到Options 的引用也可以正常工作，discriminator 列被正确填充。但是读取的数据会接收每个资源集合中所有类型的所有实体的副本（如果 Provider 有 1 个 Scooter 和 1 个 Bicycle，我将读取 2 个 Scooters 和 2 个 Bicycles，其中 Biycle 集合包含 Bicycle 和 Scooter）。解决方法是在读取实体后进行后过滤，但这不是 100% 正确的方法。
```
@OneToMany(type => Bicycle, bicycles => bicycles.provider, {cascade: true, eager: true})
bicycles: Bicycle[];


@OneToMany(type => Scooter, scooters => scooters.provider, {cascade: true, eager: true})
scooters: Scooter[];
```

用 TypeORM 框架实现这个逻辑数据模式的正确方法是什么？

【问题讨论】：

【解决方案1】：

当前的工作解决方案是用聚合替换所有的抑制。

这是一种基于对象设计的解决方案，可让 TypeORM 按预期工作。不幸的是，这个解决方案引入了很多额外的代码和计算，影响了可支持性。我想最初的问题可能有基于 TypeORM 的解决方案。

【讨论】：