プロバイダの独立型DAL（.Net）を設計する方法

Question

私は現在、クエリビルダアプリケーションを開発しています。基本的には、SQLを知らないユーザーもデータベースに関するさまざまなクエリを定義できるようなシンプルなグラフィカルインターフェイスです（結合、選択、更新、挿入、削除）。私は.Net 3.5を使用します。私のアプリケーションは複数のデータベースをサポートする必要があります.MS-SQL Server、MySQL、Oracleで動作するはずですので、に関する個別のヒントやリンクをお読みいただき、DALのプロバイダを設計する方法をお考えください。

ユーザーは、データベースサーバー、現在のサーバー上のデータベースを選択し、接続資格情報を提供し、さまざまなテーブルを選択し、一連のコンボボックスを使用してクエリを定義し、最後に有効な場合はクエリを実行します。もちろん、DALでは、各DBプロバイダのメソッドが必要です。私は工場のパターンのラインで何かを考えています。

注：これは簡単な学校プロジェクトです。そのため、結果として得られるクエリのセキュリティやパフォーマンスには関心がありません。

更新：あなたが提供した非常に貴重な情報を得て、私はDbProviderFactoryを使用することにしました。 ORMは興味深いですが、クエリアナライザ/ビルダーが必要なので、私はそれを使う点を見ません。ですから、DbProviderFactoryとそれに関連するクラスの使い方に関する詳細なチュートリアルを教えていただければ幸いです。

Answer 1

System.Data.Common.DbProviderFactoriesクラスを使用して汎用ADO.NETクラスを生成することをお勧めします。

サポートしたいデータベースの.NETプロバイダが増えたので、プロバイダのDLLをアプリケーションのパスにドロップし、app.configファイルのプロバイダのDbProviderFactoryへの参照を追加するだけです。ユーザーに、使用するプロバイダーを選択させることができます。ここで

は、トピックに関するMSDNの記事です：Obtaining a DbProviderFactory (ADO.NET)

私は前にこのアプローチを使用してマイナーな設定の変更と同じプロジェクトにMSSQLとSQLiteのを支援することができました。

ない、それはしかし、クエリビルダアプリの同様うまくいくかどうかわから...

Answer 2

私はADO.NET Entity Framework（.NET 3.5 SP1以降で利用可能）は、エンティティSQL言語でデータベース依存のSQLをかなり抽象化しているので、素晴らしい選択であると思います。

Answer 3

あなたは驚くかもしれませんが、非常に単純なプロバイダの独立DALを用いて達成することができる。

昔ながらのDataSetとのDataTable。

Answer 4

合理的に複雑なクエリを視覚的に編集すると、が非常にと厄介です。ユーザーがビジュアルデザイナーを使用してデータを挿入/削除できるようにすることは、足で自分を撃つ特定の方法です。 Management Studioのサイズダウンされたバージョン、基本的なSQLと制限されたサーバーユーザーの知識ははるかに優れた仕事をします。

まだこのアプリケーションを設計する傾向があるなら、NHibernateが必要です。より正確には、Criteria Queriesは、あなたが必要とするものにかなり近いところにマップするので、仕事をします。

Answer 5

ほとんどのORM（オブジェクト・リレーショナル・マッパー）は、さまざまなデータベース・タイプとの対話方法を知っています。

ユーザーが独自のクエリを作成できるようにするには、これに非常に注意する必要があります。事故のように、ユーザーが悪意のあるクエリを作成することはあまりありませんが（それは問題になりますが）利用可能なすべてのサーバーリソースを使用し、データベースに対して効果的なサービス拒否を作成するクエリを書くことは、驚くほど簡単です。

Answer 6

私はこれがあなたの探求を支援している場合わからないんだけど、私は最近かなり学んだと心にかかった一つのことがありますデータモデルの一意識別子の実装をデータレイヤの外部に直接伝播させるのではなく、抽象化でラップすることです。データベーステーブルのID列から、

public interface IModelIdentifier<T> where T : class 
{ 
    /// <summary> 
    /// A string representation of the domain the model originated from. 
    /// </summary> 
    string Origin { get; } 

    /// <summary> 
    /// The model instance identifier for the model object that this 
    /// <see cref="IModelIdentifier{T}"/> refers to. Typically, this 
    /// is a database key, file name, or some other unique identifier. 
    /// <typeparam name="KeyDataType">The expected data type of the 
    /// identifier.</typeparam> 
    /// </summary> 
    KeyDataType GetKey<KeyDataType>(); 

    /// <summary> 
    /// Performs an equality check on the two model identifiers and 
    /// returns <c>true</c> if they are equal; otherwise <c>false</c> 
    /// is returned. All implementations must also override the equal operator. 
    /// </summary> 
    /// <param name="obj">The identifier to compare against.</param> 
    /// <returns><c>true</c> if the identifiers are equal; otherwise 
    /// <c>false</c> is returned.</returns> 
    bool Equals(IModelIdentifier<T> obj); 
} 

あなたのビジネスロジック層、例えば（int Sなどのユニークな識別子の周りに渡された過去を持っていることがあります。たとえば、ここではモデルの識別子をラップインタフェースです）、今のような渡されます

public IPerson RetrievePerson(IModelIdentifier<IPerson> personId) 
    { 
     /// Retrieval logic here... 
    } 

あなたのデータ層は、IModelIdentifier<Person>を実装し、物理モデルの一意の識別子とその内部のデータ型を移入したクラスを持つことになります。これにより、のキー識別子をGuidに置き換えるなど、ビジネスレイヤーのデータレイヤーの変更を防ぐことができます。