DbConnection vs OleDbConnection與OdbcConnection

Question

在連接到多個可能的數據源（與數據庫無關）方面，上述每種數據庫連接方法在C＃中的主要優點是什麼？此外，在可能提供全面最佳性能的性能方面呢？

最後是否有什麼原因可以避免數據庫不可知應用程序的特定方法？

我問的原因是因爲我的應用程序目前使用Ole和我有幾個問題與使用工廠連接到某些數據庫，因此正在尋找替代品。我聽說Odbc比Ole更慢，但是有沒有背後的真相，在真實世界的應用程序中它真的很明顯嗎？

我之所以對這個問題的興趣如下：

我爲我的當前項目國家的要求，我必須有一個能夠連接到任何數據庫，但不說的先驗知識的工作數據訪問層數據庫。因此，我無法在連接方面硬編碼任何特定數據庫的任何內容。在每個給定數據庫上運行方言特定語句已經使用sql查詢工廠類型概念進行了處理。綁定變量的替換和格式也一樣。

更新：現在，我現在有一個正在使用ADO.net和數據庫提供程序工廠的代碼的工作版本。這意味着我使用Adam Houldsworth建議的基類。提供者在providerName屬性下的連接字符串中指定。連接字符串存儲在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中的東西，如果它已經不存在在machine.config您所選擇的.NET Framework版本。需要

<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;"/> 

在這個階段，我現在可以完全數據庫無關提供了正確的連接字符串使用。

Answer 1

我會避免抽象與數據庫的連接，因爲您總是以最低公分母爲目標。相反，嘗試抽象保存實體的要求。然後，抽象的每個實現都可以是數據庫特定的（基本上，針對接口進行編程）。

也就是說，我還沒有經歷過需要支持多個數據庫的實例，這是一個很難的要求。在這種情況下，所有這些惡化都會滲入YAGNI的口頭禪中。

上比較OLE DB一般ODBC等問題都可以在這裏找到：

what is the difference between OLE DB and ODBC data sources?

雖然詢問的性能問題的前期是個好東西，這個問題不能在你的應用程序上下文回答。不幸的是，只有針對樣本數據進行分析才能爲您提供所需的答案。

關於DbConnection沒有多少值得注意的地方，它是其他數據庫特定的連接類的基類。

你認爲像NHibernate這樣的ORM還是像Enterprise Library Data Access Application Block這樣的框架？這些將幫助您抽象數據庫（使用ORMs，甚至不需要在數據庫中進行任何編碼）。

更新：，只要我可以從它出現的意見告訴好像你唯一的選擇是使用所提供的.NET基類（如DbConnection）或接口（IDbConnection）。據我所知，沒有任何東西可以爲連接字符串提供正確的連接，因此您可能必須對該部分進行編碼。這樣，當您檢測到連接字符串時，您可以返回一個OleDbConnection,OdbcConnection,SqlConnection等，但在代碼中將它們用作DbConnection或IDbConnection，這樣可以讓您的代碼不受底層數據庫的影響。

不理想，但完全可行。

Answer 2

如果您需要具有不可知的數據訪問層，而不需要多次編寫數據訪問，則使用DbProviderFactory是一個不錯的選擇。

我看不到任何你想避免它的原因，並且使用System.Data.Common上的基類覆蓋了所有必要的功能。

我們在Nearforums上使用不可知的數據訪問，因爲我們提供了SQL Server和MySql數據庫腳本。關於性能，它取決於不同公司/社區提供的特定連接器（Oracle，MySql，PostgreSQL，...）的實現。大多數已知的連接器在數年內都經過了適當的測試