15

複数の可能なデータソース（データベースに依存しない）に接続するという点で、C＃の上記の各データベース接続方法の主な利点は何ですか？また、全体的に最高のパフォーマンスを提供する可能性が高いパフォーマンスの観点から？

最後に、データベースにとらわれないアプリケーションの特定の方法を回避する理由はありますか？

私が尋ねる理由は、私のアプリケーションが現在Oleを使用しており、ファクトリを使用して特定のデータベースに接続する際にいくつかの問題が発生しているため、代替案を検討しているためです。OdbcはOleよりも遅いと聞きましたが、その背後にある真実はありますか？実際のアプリケーションで本当に目立ちますか？

このテーマに興味を持った理由は次のとおりです。

現在のプロジェクトに対する私の要件では、データベースの事前知識がなくても、任意のデータベースに接続できる実用的なデータアクセス層が必要であると述べています。したがって、接続に関して特定のデータベースに固有のものをハードコーディングすることはできません。指定された各データベースでの方言固有のステートメントの実行は、SQLクエリファクトリタイプの概念を使用して処理されています。バインド変数の置換とフォーマットについても同じことが言えます。

更新：現状では、ADO.netとデータベースプロバイダーのファクトリを使用しているコードの作業バージョンがあります。これは、AdamHouldsworthによって提案された基本クラスを使用していることを意味します。プロバイダーは、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));
}

選択した.netフレームワークバージョンのmachine.configにまだ存在しない場合は、app.configまたはweb.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;"/>

この段階では、アプリケーションのクライアントバージョンを構成するときに正しい接続文字列が使用されていれば、データベースに完全に依存しなくなります。

4

2 に答える 2

5

常に最小公分母をターゲットにしているため、データベースへの接続を抽象化することは避けます。代わりに、エンティティを保存する要件を抽象化してみてください。その抽象化の各実装は、データベース固有のものにすることができます (基本的に、インターフェイスに対するプログラミング)。

とはいえ、複数のデータベースをサポートする必要があることが難しい要件だった例は一度も経験したことがありません。この場合、すべての悪化は YAGNI マントラにぶつかります。

一般に、OLE DB と ODBC の比較に関する質問は、次の場所にあります。

OLE DB と ODBC データ ソースの違いは何ですか?

事前にパフォーマンスに関する質問をするのは良いことですが、アプリケーションのコンテキストでは質問に答えることはできません。残念ながら、サンプル データに対して両方をプロファイリングするだけで、必要な答えが得られます。

について注意することはあまりありませんDbConnection。これは、他のデータベース固有の接続クラスの基本クラスです。

NHibernate のような ORM やEnterprise Library Data Access Application Blockのようなフレームワークを検討したことがありますか? これらは、データベースを抽象化するのに役立ちます (ORM を使用すると、データベースでコーディングを行う必要さえなくなるまで)。

更新:コメントからわかる限り、提供されている .NET 基本クラス ( などDbConnection) またはインターフェイス ( IDbConnection) を使用することが唯一のオプションのように見えます。私の知る限り、接続文字列の正しい接続を提供できるものは何もないため、その部分をコーディングする必要がある場合があります。このようにして、接続文字列を検出したときに 、 、 などを返すことができますが、それらをコード内で または として使用することで、コードOleDbConnectionがOdbcConnection基盤となるデータベースにとらわれないようにします。SqlConnectionDbConnectionIDbConnection

理想的ではありませんが、完全に機能します。

于 2012-04-11T08:03:34.363 に答える
3

DbProviderFactoryデータ アクセスを複数回コーディングせずに、不可知論的なデータ アクセス レイヤーが必要な場合は、を使用することをお勧めします。

それを避けたい理由は見当たらず、必要なすべての機能は の基本クラスを使用してカバーされていSystem.Data.Commonます。

SQL Server と MySql db スクリプトの両方を提供しているため、 Nearforums では不可知論的なデータ アクセスを使用しています。パフォーマンスについては、さまざまな企業/コミュニティによって提供される特定のコネクタ (Oracle、MySql、PostgreSQL など) の実装に依存します。ほとんどの既知のコネクタは、数年間にわたって適切にテストされていました。

于 2012-04-11T08:17:07.070 に答える