1

私は現在、クエリビルダーアプリケーションを開発しています。基本的には、SQLの知識がないユーザーがデータベースでさまざまなクエリ（結合、SELECT、INSERT、UPDATE、DELETE）を定義できるようにするシンプルなグラフィカルインターフェイスです。.NET3.5を使用します。私のアプリケーションは複数のデータベースをサポートする必要があり、MS-SQL Server、MySQL、およびOracleで動作する必要があるため、プロバイダーに依存しないDALの設計方法に関するヒントや関連する講義へのリンクをいただければ幸いです。

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

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

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

4

6 に答える 6

3

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

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

これは、 (ADO.NET)の取得というトピックに関する MSDN の記事です。DbProviderFactory

以前にこのアプローチを使用したことがあり、構成を少し変更するだけで、同じプロジェクトで MSSQL と SQLite をサポートできました。

ただし、クエリ ビルダー アプリでも同様に機能するかどうかはわかりませんが…</p>

于 2009-04-21T13:00:30.003 に答える
1

DataSet驚かれるかもしれませんが、プロバイダーに依存しない非常に単純な DAL は、単純な古いとで実現できますDataTable。

于 2009-04-21T12:47:25.293 に答える
1

かなり複雑なクエリを視覚的に編集するのは非常に面倒です。また、ユーザーがビジュアル デザイナーを使用してデータを挿入/削除できるようにすることは、自分自身を撃つ特定の方法です。Management Studio の縮小版であり、基本的な SQL の知識とサーバー ユーザーの制限があれば、はるかに優れた仕事をすることができます。

まだこのアプリを設計したい場合は、NHibernate が必要です。より正確には、Criteria クエリは、必要なものにかなり近いマッピングを行うため、その役割を果たします。

于 2009-04-21T12:50:48.157 に答える
0

ADO.NET Entity Framework (.NET 3.5 SP1 以降で使用可能) は、データベースに依存する SQL をエンティティ SQL 言語でほぼ抽象化するため、最適な選択肢だと思います。

于 2009-04-21T12:46:48.103 に答える
0

これがあなたの探求に役立つかどうかはわかりませんが、私が最近学んだことの 1 つは、データ モデルの一意の識別子の実装をデータ レイヤーの外部に直接伝達するのではなく、抽象化でラップすることです。たとえば、モデルの識別子をラップするインターフェイスは次のとおりです。

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 を一意の識別子として (たとえば、データベース テーブルの ID 列から)渡していた可能性があるビジネス ロジック レイヤーは、次のように渡されます。

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

データ層にはIModelIdentifier<Person>、物理​​モデルの一意の識別子を使用して内部データ型を実装および設定するクラスがあります。intこれにより、キー識別子をGuidsに置き換えるなど、データ層で行う可能性のある変更からビジネス層を隔離します。

于 2009-04-21T15:26:55.893 に答える
0

ほとんどの ORM (Object-Relational Mapper) は、さまざまな種類のデータベースと対話する方法を知っています。

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

于 2009-04-21T12:51:21.900 に答える