我们正在制作一个相当严肃的应用程序，它需要与客户想要使用的数据库保持不可知性。最初我们计划支持 MySQL、Oracle 和 SQL Server。表和视图和查询一样简单（没有真正花哨的 SQL），因此问题是：
显然选项 2 不涉及任何开销，但我认为性能不如原生访问？
【问题讨论】：
标签： c# mysql database oracle oledb
注意：如果您决定使用基本的 ADO.NET 2 功能而不是 ORM（例如 Entity Framework 或 NHibernate）或 LINQ to SQL，则此答案是相关的。
假设您在app.config 中定义了一个连接字符串：
<connectionStrings>
<add name="SomeConnection"
providerName="System.Data.SqlClient"
connectionString="..." />
</connectionStrings>
注意providerName 属性及其值的存在。您还可以为另一个数据库提供程序输入一个值，例如System.Data.SQLite.
（请注意，非标准提供程序，即默认情况下不在 .NET Framework 中的提供程序，need to be registered 首先是 app.config 或客户端计算机的 machine.config。）
现在，您可以以完全与提供者无关的方式使用指定的数据库，如下所示：
using System.Configuration; // for ConfigurationManager
using System.Data; // for all interface types
using System.Data.Common; // for DbProviderFactories
var cs = ConfigurationManager.ConnectionStrings["SomeConnection"];
// ^^^^^^^^^^^^^^^^
var factory = DbProviderFactories.GetFactory(cs.ProviderName);
// ^^^^^^^^^^^^^^^
using (IDbConnection connection = factory.CreateConnection())
{
connection.ConnectionString = cs.ConnectionString;
// ^^^^^^^^^^^^^^^^^^^
connection.Open();
try
{
using (IDbCommand command = connection.CreateCommand())
{
... // do something with the database
}
}
finally
{
connection.Close();
}
}
请注意此代码如何仅适用于接口类型。指定特定数据库提供程序的唯一位置是通过app.config 文件中的providerName 属性值。 （我已经用^^^s 标记了所有从app.config 进行设置的地方。）
Generic Coding with the ADO.NET 2.0 Base Classes and Factories:
类似于我的回答，但更详细。
ADO.NET Managed Providers and DataSet Developer Center:
除其他外，还包括可用 ADO.NET 数据库提供程序的索引。
【讨论】：
CommandText 中的命令参数。
IDbCommand.CommandText）？应该是@toDateTime（命名参数）吗？还是您使用? 令牌（位置参数）？还是其他一些语法？ ADO.NET 并没有真正为此提供独立于提供商的解决方案。
恕我直言，使用ORM 是一个很好的设计决策，以便拥有一个与数据库无关的应用程序。切换数据库可能就像更改配置设置和连接字符串一样简单。
【讨论】：
您不需要OleDbConnection 来访问非特定的 ADO.NET 提供程序。只需使用DbConnection 等。人。请参阅DbProviderFactories on MSDN 了解更多信息。
【讨论】：
通过将 Oracle 包括在该列表中，您可以保证没有什么是简单的。
换句话说，您的应用不能与 DB 无关。如果您不使用 ORM，您肯定会想要构建一个数据访问层，以便对应用程序的其余部分隐藏所有这些内容。
这里的经验之声。只是在说'。对于跨 SQL Server 和 Oracle 的通用架构，我们必须构建 ORM 的大部分基础架构，同时避免可能降低性能的方面。有趣，但不平凡，绝对！
【讨论】：
【讨论】：
没有充分的理由避免使用具有最广泛支持的最通用接口 - OleDb 甚至 ODBC，如果您对它们感到满意的话。除此之外的任何事情都会减少您可以使用的产品/语言/平台/工具/开发人员的数量。由于最接近 SQL 金属，供应商不会引入太多低效率 - 肯定少于更深奥的选项。他们已经存在了很长时间来解决任何问题。
如果您要添加一个抽象层（您自己的或其他人的），那么应该根据在您的特定上下文中引入的抽象的优点来决定，而不仅仅是拥有一个抽象层（这只是更多的支持，除非有故意的好处。）
如您所见，每个人的里程都不同。 :) 但总的来说，我认为越简单越好。
【讨论】：
为什么不使用 Microsoft 模式和实践 Enterprise Library 数据访问应用程序块。开销极小，切换供应商也很容易。
引用：
数据访问应用程序块 利用这些课程和 提供了一个模型，进一步支持 数据库封装 类型——特定的特征，例如 参数发现和类型 转换。因为这， 应用程序可以从一个移植 数据库类型到另一个没有 修改客户端代码。
【讨论】：
您始终可以通过让大部分应用程序将 DAL 用作一堆接口来使应用程序数据库的一部分不可知。然后，DAL 本身将为目标数据库提供具体的实现。
这样，您可以在 DAL 的使用中解耦，但可以从 DAL 中的性能改进或供应商特定构造中受益。
【讨论】：