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

Ive been struggling with this for like some time. If you do an architecture like 开发者_Go百科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.

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.