将EF6与自定义Api分离

Question

I would like to ask some help regarding Dependency Injection and, I think, architectural approach.

So, I have an ORM layer implemented by EF6 where the objects are described and Ef does what its business, etc. I created a custom library over it, called DatabaseApi and it is mentioned in the title as "Api", where I query the data and map it to datacontract objects. I do it for pure testing purposes. I would like to have the different libraries in my application testable.

I started to implement the code where I inject the DbContext but I don't know how to deal with the usings in this case.

I went through a few blogposts and articles about mocking and EF, especially this one but it is rather about testing EF itself and not about how to decouple it from other libraries. On the other hand, I assume my search keywords were not proper.

Do you know any good and usable tutorials and articles about how to decouple entity framework from other libraries?

Thanks in advance!

Examples:

I created an empty interface in order to the DbContext can be injectable. It is implemented by the databaseContext.

public interface IDatabase
{
}

public class DatabaseModelContext : DbContext, IDatabase{

    public DbSet<TableOne> TableOne { get; set; } 
    public DbSet<TableTwo> TableTwo { get; set; }

}

In the custom Api library constructor I put together a code to resolve the interface by Unity. I don't know whether it is working or not. I haven't executed yet.

public partial class DatabaseApi : IDatabaseApi {
    private readonly IDatabase iDatabase;

    private readonly UnityContainer unityContainer;

    public DatabaseApi()
    {
        this.unityContainer = new UnityContainer();
        this.unityContainer.RegisterType<IDatabase, DatabaseModelContext>();
        this.iDiLibDatabase = this.unityContainer.Resolve<IDiLibDatabase>();
    }
}

And here is the problem. Due to the injection I'll have and interface but there are the usings which are important to manage the resource as far as I know. How to do it?

public partial class DatabaseApi : IDatabaseApi
    {
        public List<SomeDataContract> GetMainStructure()
        {
            var result = new List<SomeDataContract>();

            //this is the old implementation
            using (var database = new DatabaseModelContext())
            {
                //some data manipulation magic... :)
            }
            return result;
        }

Answer 1

If you're okay using linq to objects as a core element of your domain access layer then exposing an IQueryable for access to the entities would work...

public interface IRepository<TEntity>
{
  IQueryable<TEntity> AllEntities { get; }
}

With that, you can do your Where, Select, etc. without hard wiring directly to EF. Behind the scenes the IRepository implementations would deal with the EF portions, database connectivity, etc. There's no avoiding coupling the to EF at the data access layer. But you can keep it constrained to just that layer using something like you've started. Just make sure the database contexts used by your IRepository objects are the only objects working with EF.

Put another way: Don't have your IDatabase return entities. Just have it deal with the connections, and you should create another layer for domain object access which takes in an IDatabase. In the example I gave, somehow the IRepository implementations would take in an instance of IDatabase.

Answer 2

So, the solution is using Autofac DI framework. I found interesting questions and answers and two really helpful tutorials. Links below:

• How do you reconcile IDisposable and IoC?
• Dependency Injection with Autofac
• Generic Repository and Unit of Work Pattern, Entity Framework, Unit Testing, Autofac IoC Container and ASP.NET MVC
• Autofac homepage