干净的架构：反转 EF DbContext 的依赖关系

Question

我偶然发现了这篇文章，它解释了干净架构的原则。我想在 ASP.NET Core + EF 中应用这些原则。我被困在这部分了：

应用层仅依赖于抽象，定义于接口，这些接口是在外层实现的。为了例如，持久性问题（例如将项目保存到数据库）仅根据要求进行定义；持久化逻辑基础设施层实现了这些要求。

听起来很合理，应用程序层不应该知道 EF 是一个东西，而只暴露一个接口，然后由基础设施层的数据库上下文实现。

然而，当我尝试时，我遇到了阻碍。假设我的数据库上下文如下所示：

public class DbContext {
   public DbSet<Person> Persons {get; set;} = null!;
}

根据 Clean Architecture，

DbContext

现在应该实现驻留在应用程序层的

IDbContext

：

public interface IDbContext {
   public DbSet<Person> Persons {get; set;}
}

但是，

DbSet

是EF中定义的类型，因此应用层也需要依赖EF，根据我对本文和Clean Architecture的理解，这是违反原则的。

文章还链接了一个存储库，当我查看应用层的依赖关系时，我发现他们实际上让应用层也依赖于 EF。

有什么想法可以摆脱这个困境并实现独立于基础设施层和 EF 的应用程序层吗？

Answer 1

有不同的方法，各有不同的缺点：