设计支持多个数据库的数据访问层

Question

我已经阅读了许多关于拥有多个数据库以及如何有效地设计DAL的帖子。在许多情况下，论坛建议应用存储库模式，这在大多数情况下都可以正常工作。

然而，我发现自己处于不同的情况。我有三个不同的数据库：Oracle、OLE DB和SQLServer。目前，存在一个唯一的DAL，其中许多不同的类将SQL查询发送到下面的层中，在相应的数据库中执行。系统的工作方式是两个数据库仅用于从中读取信息，另一个数据库用于存储相同的信息或稍后读取它。我必须提出一个更好的设计来改进当前的实现，但从架构角度来看，似乎为所有三个数据库提供一个共同的接口是不可行的。

是否有任何设计模式可以解决这种情况？我应该有三个不同的DAL吗？或者也许将存储库模式应用于此问题是可能（并且可取）的？

- Iliana

---

有趣的问题。通过改变当前的设计，你想要解决什么问题（去除重复代码，使维护更容易，简化未来的开发等）？ - dbugger

到处都有重复的代码，而且系统可能很快就会扩展，因此我希望想出一个通用的解决方案。 - Iliana

Answer 1

你的问题的答案可能会非常主观。以下是一些想法。

可以应用命令查询分离。查询侧直接与您的数据层集成，绕过任何业务或领域层，并且返回的实体经过优化以从数据库中读取和投影。该层还可以负责合并来自不同数据库调用的结果。

命令侧由命令处理程序组成，使用从您的R / W数据库映射的领域或业务实体。

通过这样做，您公开的接口将更清晰和面向业务。

我不确定完全抽象出具有自定义工作单元和存储库的数据访问层是否真的有必要：优势是否超过了劣势？他们很少这样做，因为您是否曾经更改过数据库技术？如果您这样做，这可能意味着需要重写。此外，如果您使用实体框架代码优先，您已经拥有工作单元和在数据库上的抽象；以及使用LINQ的灵活性。

底线-尽量不要过度设计/抽象事物；或使事物变得超级通用。

- L-Four

Answer 2

你的核心/业务代码不应该依赖于应用程序的DAL层中放置的任何合同/接口/类。

访问数据是应用程序的业务/核心层需要能够完成的任务，它应该能够在没有任何SQL语句的依赖和不了解底层数据访问技术的情况下完成。

我认为你需要从应用程序的核心部分中删除任何“sql”语句。 SQL是供应商相关的，对特定数据库引擎的任何依赖都需要清除你的核心，并将其移动到DAL所属的位置。然后，您需要创建界面，这些界面位于DAL之外，然后在一个或多个DAL模块/类中为其创建实现类。您的DAL可以依赖于您的核心，但反过来则不行。

我不明白为什么不能在这种情况下使用存储库层。当我有一个只能读取的数据库时，我通常会让存储库接口的名称表明这一点，例如ICompanyRepositoryRead。

- Fredrik Rudberg