n Layered Asp.net app with Entity framework

Question

I am facing the same issue as the one below

Entity Framework 6 and Unit Of Work… Where, When? Is it like transactions in ado.net?

As per the answer, i shouldn't create an abstraction layer over EF, but i want to keep my business layer independent. So i decided to go with the last option, adding TransactionScope. But i read, that it affects the performance. I have kept the IsolationLevel to ReadCommitted. But i am not sure about the performance.

So how can i use EF without adding its dependency to business layer.

My business objects are different from Entity objects.

Answer 1

If you don't want to draw a dependency on EF, you're going to have to abstract it out. The poster in the response you mentioned believes this is too much code, but if you want to decouple the data layer implementation from the business layer it's a necessary evil.

Historically I've gone with a relatively generic IRepository implementation that's generated from an IUnitOfWork such as:

uow.Get<IRepositoryType>()

By using an IoC container (using TinyIoC lately) we're able to handle and swap out our implementations easily, and keep our domain object separate from our data objects.