我已经阅读了许多关于拥有多个数据库以及如何在这种情况下有效设计DAL的问题。在许多情况下，论坛建议应用存储库模式，在大多数情况下都能正常工作。
然而，我发现自己处于不同的境地。我有3个不同的数据库：Oracle，OLE DB和SQLServer。目前，存在具有许多不同类的唯一DAL，其将SQL查询发送到下面的层以在相应的数据库中执行。系统工作的方式是两个数据库仅用于从中读取信息，另一个用于存储相同的信息或稍后读取。我必须为当前的实现提出一个更好的设计，但从架构的角度看，似乎所有三个数据库的通用接口都不合理。
是否有任何设计模式可以解决这种情况？我应该有三种不同的DAL吗？或者可能（并且建议）将存储库模式应用于此问题？
答案 0 :(得分：1)
您的问题的答案可能会非常主观。这些是一些想法。
您可以应用命令查询分离。查询端直接与您的数据层集成，绕过任何业务或域层，并且返回的实体针对从数据库中读取和项目进行了优化。该层还可以负责合并来自不同数据库调用的结果。
命令端由命令处理程序组成，使用从R / W数据库映射的域或业务实体。
通过这样做，您公开的界面将更加清晰，面向业务。
我不确定是否真的需要使用自定义工作单元和存储库来完全抽象出数据访问层：优势是否优于缺点？他们很少这样做，因为你会改变数据库技术吗？如果你这样做，这可能意味着重写。此外，如果您首先使用实体框架代码，那么您已经拥有了工作单元和数据库之上的抽象;以及使用LINQ的灵活性。
底线 - 尽量不要过度设计/过度抽象;或者使事物超级通用。
答案 1 :(得分：0)
您的核心/业务代码永远不应该依赖于放置在应用程序的DAL层中的任何合同/接口/类。
访问数据是应用程序的业务/核心层需要能够做到的事情，并且它应该能够在没有任何SQL语句依赖性的情况下完成，并且不需要了解底层数据访问技术。
我认为您需要从应用程序的核心部分删除任何“sql”语句。 SQL依赖于供应商，并且对特定数据库引擎的任何依赖都需要从您的核心清除，并移动到它所属的DAL。然后，您需要创建位于DAL之外的接口，然后在一个或多个DAL模块/类中创建实现类。您的DAL可能取决于您的核心，但不是相反。
我不明白为什么在这种情况下不能使用存储库层。当我有一个我只能读取的数据库时，我通常会让存储库接口的名称表明这一点，就像ICompanyRepositoryRead一样。