Decoupling EF6 from its custom 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;
        }

You can declare `IDbSet` members in `IDatabase` and implement them explicitly. For `using...dispose`, you'll have to use an IOC container that handles disposable objects. Unity does not do this out of the box, but there is an implementation of a `TransientDisposableLifetimeManager` for Unity out there if you search for it. I don't know about other IOC containers. — Keith Payne, Nov 28 '14 at 17:51
Keith, thanks for the suggestions. Based on your suggestion I found AutoFac and interesting articles, tutorials about it. Thanks! I've found the solution for my problem! :) http://stackoverflow.com/questions/987761/how-do-you-reconcile-idisposable-and-ioc https://github.com/autofac/Autofac http://www.codeproject.com/Articles/25380/Dependency-Injection-with-Autofac — AndrasCsanyi, Nov 29 '14 at 12:07
Keith, how can I mark your answer as the solution I looked for? — AndrasCsanyi, Dec 18 '14 at 20:32
Since I only had a helpful comment and you found the answer to your question yourself, you should post an answer that explains what you found, including some of your own code perhaps, and mark it as the answer. This way others who may be searching for the answer to the same or similar problem can find yours. — Keith Payne, Dec 19 '14 at 15:24
Try to look at the Repository pattern. Ie here: http://www.codeproject.com/Articles/526874/Repositorypluspattern-cplusdoneplusright — Morten Frederiksen, Dec 19 '14 at 18:20

Trevor Ash · Answer 1 · 2014-11-28T17:39:21.137

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.

Unfortunately, this is not effective when you try to perform a Unit Of Work with different entities. — Keith Payne, Nov 28 '14 at 17:55

score 0 · Accepted Answer · edited May 23 '17 at 12:20

0

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

edited May 23 '17 at 12:20

Community

1
1

answered Dec 19 '14 at 17:48

AndrasCsanyi

3,943
8
45
77

Decoupling EF6 from its custom Api

2 Answers2