【问题标题】:TypeORM run transaction on provider level?TypeORM 在提供者级别运行事务?
【发布时间】:2019-08-26 21:37:55
【问题描述】:

我有两张桌子accountaddressaccount 依赖于address 含义,要创建account,必须先创建address 并获取address.id

如果address 创建失败或account 创建失败,我不能依赖我的数据库。

因此我必须运行一个事务

如果我在我的 provider 中运行事务,该类注入所有必需的服务以执行我需要的操作,即创建帐户,在我的情况下,它使用 @987654330 @ 和 accountService,有人告诉我这是一种反模式,因为事务和与数据库相关的所有内容都必须在 repository 中运行。

但是怎么做呢?我必须在 addressRepositoryaccountRepository 两个不同的存储库中运行操作。

当您在两个不同的服务上使用多个存储库时,启动和提交事务的最佳做法是什么?

【问题讨论】:

    标签: nestjs typeorm


    【解决方案1】:

    我建议您创建另一个 Service (addressAcountService) 并仅在此服务中使用您使用这两个实体的操作,这是我认为最安全的方法。

    在服务方法上,我没有看到在存储库逻辑中添加层的任何反模式,因为我可以看到将存储库分离为服务使系统更加可扩展可维护,因为您正在防止代码重复,您甚至可以防止访问项目中您不希望他们在不受控制的情况下修改数据库的不同位置,如果您想更改为,它甚至可以防止将来发生这种情况一个不同的 DBMS 甚至 ORM 你只需要改变依赖而不是整个 CRUD 操作的实体逻辑。举个例子,假设在您的应用程序的早期开发中,您决定在用户​​想要的时候对数据库中的所有行进行硬DELETE,随着系统开始增长,您检测到删除操作在哪里没有最安全的操作,因为您有很多级联删除,并且在某些情况下删除一行需要很长时间(我在这里夸大了一点)然后您想将其更改为软(UPDATE 一个标志)删除,如果您正在使用存储库进行所有操作,这将是一个令人头疼的问题,因为您需要更改使用存储库的代码的每个部分及其级联关系,我们是不只讨论 DELETE 操作,您必须注意 SELECTs UPDATEs 甚至是 INSERTs您寻找独特的属性。在服务方法中,您更改了可用于不同控制器的操作中的逻辑,就是这样,甚至您可以创建另一个服务并替换依赖项。

    【讨论】:

      猜你喜欢
      • 2020-07-19
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-01-05
      • 1970-01-01
      • 2021-02-23
      • 2020-07-14
      • 1970-01-01
      相关资源
      最近更新 更多