Architecture so you can swap entity framework for SQL and vise versa

Question

Ive been struggling with this for like some time. If you do an architecture like this..

Project.Domain
- Entities
- Repositories interfaces Project.Persistence.EF
- Repositories
- ContextProvider
- etc.. 
Project.Persistence.SQL 
??? 
Project.Tasks 
... 
Project.Presentation 
...

With an IoC you can almost change any components for others components.. The important interface here which is related to the question is IRepository (Generic) located at the domain. That only the definition, not the implementation.

The main problem i was looking at is How i can switch EF for SQL in almost no time ?

If you look at the repository interface.. it is intended to work with a context obviously.

public interface IRepository<T> where T : class
{
    void Add(T entity);
    void Delete(T entity);
    T GetById(long Id);
}

How i can then make this repository to work also with an SQL implementation so i can use a IoC to choose betwen EF and SQL ?

Sure i could make IRepositorySQL and IRepositoryEF but then i wouldnt be able to use an IoC for this... and im stuck again.

Any ideas or suggestion or way to do things ?

Thanks.

You should really decide on your approach and then stick to it, there is very little value in switching between inline SQL or using an ORM — Kane, Sep 16 '11 at 11:45
What do you mean with "it is intended to work with a context?" I see no reference in `IRepository` that requires any sort of context... — Mark Seemann, Sep 16 '11 at 11:55
Not wrong. Its because i try to find a solution where you could be really flexible but i think ive missed the point.. — Rushino, Sep 16 '11 at 11:55
@Mark Seemann Well its because of the methods. There no way you can update using SQL. There only Add and Remove. EF autotrack changes but SQL do not. — Rushino, Sep 16 '11 at 11:57
@Mark Seemann I know. This is why it IS intented to be used with EF.. because it don't have an Update method. In EF you don't need an update method so why include it in repository ? Objects are tracked. — Rushino, Sep 16 '11 at 13:47

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

The main point in abstracting data layer to universal solution is to throw away all specific features:

You will throw away LINQ because it is specific feature of some ORM
You will throw away lazy loading because it is specific of some ORM
You will throw away change tracking or implement your own change tracking
etc.

You will also throw away generic approach. Generic approach will be useful only as a base interface for specific repositories. All specific features will be used only inside repositories and using repositories must not have any side effects because these side effects don't have to happen when using different implementation.

Any advanced feature which should be provided by universal solution must be implemented from scratch and correctly interpreted inside specific implementation. That leads to series of patterns like Repository, Unit of Work or Specification. If you don't abstract advanced features you will have only solution with feature set equal to most limited specific implementation.

Because of that this should be done only if it is absolutely necessary = it is one of the main product requirements. Otherwise it is waste of time and money.

+1 Data access is part of the architecture. If you need to change data access, you need to change the architecture. — Kristof Claes, Sep 16 '11 at 14:11

Architecture so you can swap entity framework for SQL and vise versa

1 Answers1