NestJS与抽象类集合的关系

Question

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

Diagram source code

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

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

我尝试了official Entity Inheritance documentation

中介绍的两个选项

1. “混凝土表继承”方法（正在使用带有@Entity子类的抽象类）无法正常工作，因为Option实体定位到不是有效实体且没有数据库表的AbstractResource实体。

2. “单表继承”方式也无法立即使用，因为当我将Provider及其AbstractResoruce集合作为信号请求持久化时，我在type discriminator列中看到AbstractEntitiy。我尝试在持久化之前将具有该名称的属性显式添加到具有正确值的子类，但是在持久化期间此值将被覆盖。

   @Entity()
   @TableInheritance({
       column: { name: 'discriminator', type: 'varchar' }
   })
   export abstract class Resource{
   

3. “最有效”的方式是“单表继承”，但在Provider内针对每种子实体类型都具有独立的集合。这样，持久性就可以正常工作，从AbstractResource到Options的引用也可以正常工作，discriminator列可以正确填充。但是读取的数据会收到每个资源集合中所有类型的所有实体的副本（如果Provider有1个踏板车和1个自行车，我将读取2个踏板车和2个自行车，其中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框架实现此逻辑数据模式的正确方法是什么？

Answer 1

当前有效的解决方案是用聚合代替所有不稳定性。

1. 我重构了实体以避免任何继承和抽象类： Diagram sources

2. 我介绍了具有最初所需的对象布局和层次结构的业务对象层

3. 与实体转换映射器之间实现业务

这是一个基于对象设计的笨拙解决方案，可使TypeORM正常工作。不幸的是，该解决方案引入了许多额外的代码和计算，因此可支持性受到影响。我想最初的问题可能有基于TypeORM的解决方案。