我需要编写一些服务，其方法需要执行两个工作单元，即使第一个工作单元失败并被回滚，第二个工作单元也会执行。 创建和回滚事务是不够的，因为 DbContext 仍然记住第一个工作单元的更改。 因此我需要两个 DbContext。 因为我使用其他服务来执行工作本身，所以我需要将 DbContext 提供给它们，并且我希望将其注入，而不是手动创建或通过服务定位器获取。
通常的方法是注入 IServiceScopeFactory，创建作用域并从中解析工作中涉及的服务（DbContext 来管理事务，以及一些服务使用此 DbContext 来完成工作）。我不喜欢这一点的是，包含服务或其方法的签名中没有任何地方是需要这些服务的信息，并且我的服务了解 IServiceScopeFactory，因此至少了解有关使用的 DI 框架的一些信息。
我想要一种解决方案，让我的服务尽可能少地了解 DI 框架（允许知道概念上存在范围，但不应依赖于 DI 框架中的任何类/接口）。
为我需要从范围中解析的每个依赖项注入某种结果类型为 IDisposable（或标记接口，但我不喜欢这些）的范围工厂和服务工厂方法，从范围对象解析服务。
这样我可以使用 DI 框架或手动创建所需的对象，并且在手动创建它们时，我不能错过依赖项，因为我知道它，因为我必须提供服务工厂。