Where do EntityFramework and IoC interfaces belong in an onion architecture?

Question

I recently discovered the Onion Architecture pattern by Jeffrey Palermo and decided to use it for a current project out of curiousity. After I had to replace my IoC framework (Unity) with another one (Ninject) because of a bug that made it completely unusable for my project, I noticed that I had made the right decision because I only had to change a few parts in my application and it still ran like a charm.

However, I haven't figured out where certain interfaces that relate to Entity Framework and IoC belong to in this pattern. Let's say I have an interfaces for my database context:

public interface IDatabaseContext : IDisposable {

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

}

Is this now a domain interfaces? Or an infrastructure interface? The need of a interface member of type IDbSet<>'1 tightly couples the interface to Entity Framework, but I need a way to inject a transient instance of my database context into a repository. Does IoC even fit into the onion architecture? What do you think about this structure:

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

Answer 1

Dependency Injection (DI) fits very well into an Onion Architecture; that's where you should end, if you correctly apply DI.

Interfaces should be defined and owned by the clients that consume the interfaces. As Agile Principles, Patterns, and Practices explain, "clients […] own the abstract interfaces" (chapter 11). Thus, any attempt to define a data-centric interface like IDatabaseContext is bound to cause problems sooner or later, because it's violating various SOLID principles like the Dependency Inversion Principle or the Interface Segregation Principle.

Instead, your client code should define the interfaces that they require. Then you can always implement those interfaces with Entity Framework.