C# 具有多个数据源的数据层体系结构

我正在尝试创建一个允许您切换多个数据源的系统，例如，从实体框架切换到Dapper。我正试图找到最好的方法来做到这一点

目前，对于不同的数据层，我有不同的项目，例如，对于实体框架，

data.EF

，对于Dapper，

data.Dapper

。我使用了数据库方法，但当它创建模型时，生成的信息耦合在一起，不容易重构，例如模型分离

我有一个名为models的项目，它包含域和视图模型，我正在考虑创建

Data.Core

并遵循存储库模式。但是，这样做会增加一个额外的层，这样我就有了表示/业务/存储库/数据

---

我想知道这种方法的最佳结构。我是否也应该使用代码优先的方法来创建数据库？这有助于分离关注点并改进抽象。这是一个相当大的应用程序，因此获得正确的结构至关重要。

我建议您创建域对象，使用代码优先的方法，并应用存储库模式

我建议通过实体的存储库接口将数据接口分解为模型或基础设施项目。（我认为后者是您创建

Data.Core

项目的基本原理。）

然后，每个数据源将实现完全相同的接口集，您可以轻松地在它们之间切换，甚至可以使用依赖项注入进行动态切换

例如，使用存储库：

Model
  \_ Entities
       Entity
  \_ Repositories
       IEntityRepository    

Data.EF      
   EntityRepository : Model.IEntityRepository

Data.Dapper
   EntityRepository : Model.IEntityRepository

---

那么，在您的业务中，您甚至不需要引用

Data.EF

或

Data.Dapper

：您可以使用

IEntityRepository

，并动态注入该引用。

我认为您的方法是正确的。我想说，现在演示/业务/存储库/数据是相当标准的

我认为使用POCO的代码优先方法是当今业界的首选方法。我建议开始创建一个包含POCO数据结构的项目，其中包含任何逻辑，并从那里开始。这样做的好处是，对象可以更自然地对域进行建模。如果从以数据库为中心的方法开始，问题在于，如果不小心，可能会以更类似于SQL关系数据库而不是真实模型的对象结束。在.net的第一个版本中，这一点非常明显，鼓励它使用与db紧密结合的数据集，这常常导致在业务层处理问题

---

如果需要，您可以在存储库层中的业务对象和db对象之间进行任何复杂的映射。如果需要，您可以使用代理和/或工作单元。

是的，存储库模式确实带来了一个额外的层。更多详细信息，请看这篇文章

RE：代码优先创建数据库的方法

---

不管你的应用程序有多大，问题在于你还打算用数据库做什么。如果此数据库只是此应用程序的存储库，则可以先使用代码，因为您只是存储代码对象。但是，如果您将此数据库用作应用程序之间的集成点，则可能希望将数据库与应用程序模型分开设计。

谢谢您的评论。非常好的建议，很高兴走上正轨。