我有一种情况，我需要创建一个支持多个数据库的应用程序。多个数据库意味着客户端可以首先使用任何数据库，如 Oracle、SQL Server、MySQL、PostgreSQL。
我试图使用像 NHibernate 或 MyBatis 这样的 ORM。但它们有其局限性，需要专业知识才能使用。
所以我决定使用微软提供的数据提供者，如 ADO.NET、OLEDB、ODP.NET 等。
有什么办法可以让我的数据库逻辑对所有数据库保持相同？我已经尝试过IDbConeection，IDbCommand等等，但在 Oracle（参考光标）的情况下它们会出现问题。
我有什么办法可以做到这一点？一些链接或指南将不胜感激。
编辑：
DBTypes 存在问题，因为它们是枚举定义不同的数据提供者。
好吧，现实生活中的应用程序就是这样复杂的。在不知不觉中，您想用 App 替换 UI，将您的逻辑公开为 WCF 服务，用另一个服务提供商更改电子邮件服务，在模拟 DAL 的同时测试您的代码片段，并用另一个更改数据库.
处理这个问题的常用方法是通过将实现与调用者分开的接口传递所有调用。之后，您可以实现不同的 DAL。
我个人通常采用这种方法：
基本上，您现在拥有一个可以与单个数据库、邮件提供商等一起使用的工作软件。到目前为止一切都很好。
接下来，重新设计工厂。基本上，您希望使用配置设置为您的数据选择正确的提供程序（实现您的接口的正确 DLL）。在大多数情况下，一个简单的开关就足够了。
在这一点上，我通常养成为接口进行大量单元测试的习惯。
最后一步是为不同的数据库提供程序创建 DLL。其中之一将在您的应用程序运行时加载。
我更喜欢简单的 Linq 而不是 SQL（我也使用来自 LinqConnect 的库），因为它非常快。我只是从复制粘贴另一个数据库提供程序开始，然后重新设计它直到它工作。就我个人而言，我不再相信神奇的“支持所有 sql 数据库”解决方案：根据我的经验，某些数据库处理某些查询的速度比其他数据库快得多 - 这意味着您最终可能会得到一些自定义代码反正每个数据库。
这也是您的单元测试真正获得回报的地方。基本上，您可以从复制粘贴开始并进行测试。如果你幸运的话，一切都会以不错的表现立即运行......如果没有，你知道从哪里开始。
经久耐用
建立持久的东西。事情会改变：
实体框架呢
我已经看到很多客户因此而在性能方面遇到麻烦。在我测试它的许多次中，我有同样的经历。我注意到客户围绕 EF 进行大量查询以获得一些不错的性能。
公平地说，我几年前就放弃了，我知道他们已经取得了相当大的性能改进。尽管如此，我还是会在考虑之前对其进行测试（尤其是复杂的查询）。
如果我要使用 EF，我会在“数据库公用 DLL”中实现所有 EF 内容，然后从中派生类。正如我所说，并非所有数据库都与查询相同 - 您可能希望实施一些获得良好性能所必需的技巧。你的测试会告诉你。
奖金
通过接口编程的其他原因与代理相结合有很多优势。仅举几例，您可以通过简单地实现相同的接口轻松创建日志接收器、缓存、统计信息、WCF 等。如果有一天你讨厌你当前的 OR 映射器，你可以把它扔掉，而不用触及应用程序的任何一行。
是的，有可能。
现在正在处理相同的场景，我的所有逻辑相关数据（通常您可以调用元数据）都驻留在一个数据库中，而日期驻留在另一个数据库中。
你需要做什么。您应该在两个不同的文件中有连接相关参数，或者您可以将这些文件称为道具文件。现在你需要有连接具体类，它从这些道具文件中获取参数。因此，您需要创建连接的地方只需提供道具文件，它将根据需要创建数据库连接。
编写微服务并使用rest api连接它们怎么样？你（也许你的团队）可以提供一个处理逻辑和用户界面的核心应用程序。这仍然基于您当前的技术。但不是直接添加某种数据库连接，您可以提供多种类型的微服务（基于 asp.net 或 core），提供一个 rest api。您可以从此类微服务中的每个数据库中获取数据。因此，您将为例如 MySQl 开发一个微服务，为 MsSQL 开发另一个微服务，当新客户提出 oracle 时，您编写一个新的小型微服务来处理您预期的 API。
更多信息（基于 .net 核心）在这里：https ://docs.asp.net/en/latest/tutorials/first-web-api.html
我认为这是一个团队讨论，您决定使用哪种技术。但今天我建议写一个微服务。它使得为例如移动设备附加新应用程序也变得更加容易:)
我相信微软的数据访问组件会适合你。 https://en.wikipedia.org/wiki/Microsoft_Data_Access_Components