EntityFramework 和 IoC 接口在洋葱架构中属于哪里？答案

【问题标题】：Where do EntityFramework and IoC interfaces belong in an onion architecture?EntityFramework 和 IoC 接口在洋葱架构中属于哪里？
【发布时间】：2014-03-02 11:23:42
【问题描述】：

我最近发现了 Jeffrey Palermo 的洋葱架构模式，并出于好奇决定将其用于当前项目。在我不得不将我的 IoC 框架 (Unity) 替换为另一个 (Ninject) 之后，因为一个错误导致它对我的项目完全无法使用，我注意到我做出了正确的决定，因为我只需要更改我的几个部分应用程序，它仍然像魅力一样运行。

但是，我还没有弄清楚与实体框架和 IoC 相关的某些接口在此模式中属于何处。假设我有一个用于数据库上下文的接口：

public interface IDatabaseContext : IDisposable {

   IDbSet<T> Set<T>() where T: class;

}

这现在是域接口吗？还是基础设施接口？需要 IDbSet'1 类型的接口成员将接口与实体框架紧密耦合，但我需要一种将数据库上下文的瞬态实例注入存储库的方法。 IoC 甚至适合洋葱架构吗？您如何看待这种结构：

MyProject.Domain
    - Entities
        - MyEntity.cs
MyProject.Domain.Interfaces
    - IDatabaseContext.cs       // that doesn't fit here, right?
    - IMyEntityRepository.cs
MyProject.Infrastructure
    - Repositories
        - MyEntityRepository.cs
        - DatabaseContext.cs
    - Migrations
        ...
MyProject.Web
    - ... // web stuff
    - NancyBootstrapper.cs
MyProject.Application
    - Services
        - ISnmpClientService.cs
        - SnmpClientService.cs
MyProject.Server
    - KernelHelper.cs 
    - IKernelResolver.cs

【问题讨论】：

只是一个没有参考的意见，但数据库上下文对我来说确实感觉像基础设施。在我看来，该域应该只针对（注入的）存储库接口，甚至不知道存储库在哪里找到/存储数据。存储库很可能在其实现中具有注入的数据库上下文，但域不应暴露于该细节。

标签： c# design-patterns dependency-injection domain-driven-design inversion-of-control

【解决方案1】：

依赖注入 (DI) 非常适合洋葱架构； that's where you should end, if you correctly apply DI.

接口应该由使用接口的客户端定义和拥有。正如Agile Principles, Patterns, and Practices 解释的那样，“客户 […] 拥有抽象接口”（第 11 章）。因此，任何定义像IDatabaseContext 这样以数据为中心的接口的尝试迟早都会引起问题，因为它违反了依赖倒置原则或接口隔离原则等各种 SOLID 原则。

相反，您的客户端代码应该定义它们所需的接口。然后，您始终可以实现这些接口与实体框架。

【讨论】：