架构，以便您可以将实体框架交换为SQL，反之亦然

Question

我已经为此挣扎了一段时间了。如果你做这样的架构…

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

使用IoC，您几乎可以为其他组件更改任何组件。这里与问题相关的重要接口是位于域的IRepository (Generic)。那只是定义，而不是实现。

我正在寻找的主要问题是我如何能切换EF SQL在几乎没有时间

如果你看一下存储库接口…显然，它的目的是与上下文一起工作。

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

我如何使这个存储库也与SQL实现一起工作，以便我可以使用IoC在EF和SQL之间进行选择?

当然我可以让IRepositorySQL和IRepositoryEF，但这样我就不能使用IoC了…我又卡住了。

有什么想法、建议或方法吗?

谢谢。

Answer 1

将数据层抽象为通用解决方案的要点是抛弃所有特定的特性:

• 你将抛弃LINQ，因为它是某些ORM的特定功能
• 你将抛弃惰性加载，因为它是特定于某些ORM的
• 您将抛弃变更跟踪或实现您自己的变更跟踪
• 等。

你也会抛弃泛型方法。通用方法仅作为特定存储库的基本接口有用。所有特定的特性只能在存储库中使用，并且使用存储库不能有任何副作用，因为这些副作用在使用不同的实现时不必发生。

任何应该由通用解决方案提供的高级特性必须从头开始实现，并在特定实现中正确解释。这导致了一系列的模式，如存储库、工作单元或规范。如果你不抽象高级特性，你就只能用与最有限的具体实现相同的特性集来解决问题。

因此，只有在绝对必要的情况下才应该这样做=这是主要的产品要求之一。否则就是浪费时间和金钱。