DbConnection vs OleDbConnection vs OdbcConnection

本文关键字：vs OdbcConnection OleDbConnection DbConnection | 更新日期: 2023-09-27 18:30:38

在连接到多个可能的数据源（与数据库无关）方面，上述每种数据库连接方法的主要优点是什么？另外，在性能方面，哪个可能提供全面的最佳性能？

最后，是否有任何理由避免为数据库无关的应用程序使用特定方法？

我问的原因是因为我的应用程序目前使用 Ole，我在使用工厂连接到某些数据库时遇到了一些问题，因此正在寻找替代方案。我听说 Odbc 比 Ole 慢，但这背后有什么道理吗，它在现实世界的应用程序中真的很明显吗？

我对这个主题感兴趣的原因如下：

我对当前项目的要求是，我必须有一个工作数据访问层，该层能够在不事先了解该数据库的情况下连接到任何数据库。因此，就连接而言，我无法对任何给定数据库的特定内容进行硬编码。在每个给定数据库上运行特定于方言的语句已使用 sql 查询工厂类型概念进行处理。绑定变量的替换和格式化也是如此。

更新：就目前而言，我现在有一个使用 ADO.net 和数据库提供程序工厂的代码工作版本。这意味着我正在使用Adam Houldsworth建议的基类。提供程序在连接字符串中的提供程序名称属性下指定。连接字符串存储在 app.config 中，我的数据库连接类可以在其中检索它。如果安装了正确的驱动程序，例如 npgsql 或 Oracle 的 odac 包，那么工厂将正常工作。下面是我的代码示例，显示了使用提供程序工厂的连接对象的基本构造函数。

private readonly DbFactoryBindVariables m_bindVariables;
private readonly DbProviderFactory m_provider;
private string m_connectionString = String.Empty;
private readonly string m_providerName = String.Empty;
private DbConnection m_dbFactoryDatabaseConnection;

/// <summary>
/// Default constructor for DbFactoryDatabaseConnection.
/// </summary>
public DbProviderFactoryConnection()
{
        m_providerName = ConfigurationManager.ConnectionStrings["ApplicationDefault"].ProviderName;
        m_provider = DbProviderFactories.GetFactory(m_providerName);
        m_dbFactoryDatabaseConnection = m_provider.CreateConnection();
        m_connectionString = ConfigurationManager.ConnectionStrings["ApplicationDefault"].ConnectionString;
        m_dbFactoryDatabaseConnection.ConnectionString = m_connectionString;
        m_bindVariables = new DbFactoryBindVariables(m_dialect.ToLower(), DbFactoryBindSyntaxLoader.Load(this));
}
可能需要将

类似于以下内容的内容添加到 app.config 或 web.config 中，如果所选 .net 框架版本的 machine.config 中尚不存在这些内容。

<system.data>
    <DbProviderFactories>
       <add name="Npgsql Data Provider" 
        invariant="Npgsql" 
        support="FF" 
        description=".Net Framework Data Provider for Postgresql Server"
        type="Npgsql.NpgsqlFactory, Npgsql, Version=2.0.1.0, Culture=neutral, 
        PublicKeyToken=5d8b90d52f46fda7" />
    </DbProviderFactories>
</system.data>

所需的连接字符串：

<add name="ApplicationDefault" connectionString="DATA SOURCE=TNSNAME;PASSWORD=PASS;USER ID=USER;" providerName="Oracle.DataAccess.Client;"/>

在此阶段，如果在配置应用程序的客户端版本时使用正确的连接字符串，我现在可以完全与数据库无关。

DbConnection vs OleDbConnection vs OdbcConnection

我会避免抽象到数据库的连接，因为您始终针对最低公分母。相反，尝试抽象保存实体的要求。然后，该抽象的每个实现都可以特定于数据库（基本上是针对接口进行编程）。

也就是说，我从来没有遇到过需要支持多个数据库是一项硬要求的情况。在这种情况下，所有这些恶化都符合 YAGNI 的口头禅。

有关将 OLE DB 与 ODBC 进行比较的问题通常可以在此处找到：

OLE DB 和 ODBC 数据源之间有什么区别？

尽管预先询问性能问题是一件好事，但无法在应用程序的上下文中回答该问题。遗憾的是，只有根据样本数据对两者进行分析才能为您提供所需的答案。

关于DbConnection没有什么需要注意的，它是其他特定于数据库的连接类的基类。

您是否考虑过像NHibernate这样的ORM或像Enterprise Library Data Access Application Block这样的框架？这些将帮助您抽象数据库（使用ORM，甚至不需要在数据库中进行任何编码）。

更新：据我从评论中可以看出，您唯一的选择似乎是使用提供的 .NET 基类（例如 DbConnection ）或接口（IDbConnection）。据我所知，没有任何东西可以为您提供连接字符串的正确连接，因此您可能需要对该部分进行编码。这样，当您检测到连接字符串时，您可以返回 OleDbConnection 、 OdbcConnection 、 SqlConnection 等，但在代码中将它们用作DbConnection或IDbConnection，从而使您的代码与基础数据库无关。

不理想，但完全可行。

如果需要具有不可知的数据访问层，而无需多次对数据访问进行编码，则使用 DbProviderFactory 是一个不错的选择。

我看不出您有任何理由要避免它，并且使用 System.Data.Common 上的基类涵盖了所有必要的功能。

我们在Nearforums上使用不可知的数据访问，因为我们同时提供SQL Server和MySql db脚本。关于性能，这取决于不同公司/社区提供的特定连接器（Oracle，MySql，PostgreSQL等）实现。大多数已知的连接器在几年内都经过了适当的测试。

相关文章：