c# - C# プロジェクトのどこに SQL ステートメントを配置しますか?

Question

vb6 アプリケーションの c# への移植を担当する予定です。このアプリケーションは、アクセスデータベースとやり取りする Windows アプリです。データアクセスは、基本的なビジネスオブジェクトにカプセル化されています。基本的に1テーブル1クラス。既存の vb6 ビジネスオブジェクトは、DAO を介して DB の読み取りと書き込みを行います。以前に DAL と ORM を数回書いたことがありますが、それらはすべて SQL Server のみを対象としていました。これは、アクセスと SQL サーバーをターゲットにする必要があります。以前のプロジェクトでは、SQL 文字列をビジネスオブジェクトのプライベートパーツに配置し、接続やコマンドの作成などの冗長な SQL コードを共通の基本クラスに移動して、コードを削減していました。

今回は、SQL 文字列を .settings ファイルまたはその他のキー/値型のテキストファイルに書き込むことを考えています。次に、SQL ユーティリティを作成してこのファイルを編集し、パラメータ化されたクエリを実行してテストできるようにします。これらのクエリは、SQL をコードに埋め込むのではなく、ビジネスオブジェクトで名前で参照されます。

標準的なアプローチは、対象となるデータベースごとに DAL を作成し、どの DAL を使用するかを構成状態にすることです。データベースごとに 2 つの DAL クラスを作成したくありません。キー名で正しいクエリを参照し、適切なタイプの接続があれば、コードが少なくなるようです。

それで、あなたたちはこのようなことをしていますか？この問題にどのように取り組みましたか、または取り組みましたか? あなたに最適なものは何ですか？

ありがとう！

score 41 · Accepted Answer

まあ、たくさんのオプションがあります - それはあなたの最も差し迫ったニーズが何であるかに本当に依存します:-)

1 つの方法として、VS ソリューション内で SQL ステートメントをテキストファイルとして作成し、それらを「ビルドアクション」で「埋め込みリソース」としてマークすることが考えられます。このようにして、SQL は結果のアセンブリに含まれ、実行時に .NET フレームワークの ResourceManifestStream を使用して取得できます。

private string LoadSQLStatement(string statementName)
{
    string sqlStatement = string.Empty;

    string namespacePart = "ConsoleApplication1";
    string resourceName = namespacePart + "." + statementName;

    using(Stream stm = Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName))
    {
        if (stm != null)
        {
            sqlStatement = new StreamReader(stm).ReadToEnd();
        }
    }

    return sqlStatement;
}

「ConsoleApplication1」を、SQL ステートメントファイルが存在する実際の名前空間に置き換える必要があります。完全修飾名を使用してそれらを参照する必要があります。次に、次の行で SQL ステートメントをロードできます。

string mySQLStatement = LoadSQLStatement("MySQLStatement.sql");

ただし、これにより、クエリはかなり「静的」になります。たとえば、実行時に構成および変更することはできません。コンパイルされたバイナリビットに直接焼き付けられます。一方、VS では、C# プログラムコードと SQL ステートメントがきれいに分離されています。

実行時にそれらを微調整して変更できるようにする必要がある場合は、キーワードと実際の SQL クエリをフィールドとして含む単一の SQL テーブルにそれらを配置します。その後、必要に応じてそれらを取得して実行できます。これらはデータベーステーブルにあるため、アプリ全体を再デプロイすることなく、実行時であっても自由に変更、修正、修正することができます。

マルク

score 14 · Accepted Answer

本当に必要な場合は、クエリを個々の *.sql ファイルに入れ、それを Resources.resx に含めます。その中に「ファイル」セクションがあり、埋め込みリソースファイルを含めることができます。

その後、生成された Resources.MyQuery プロパティを使用できます。これにより、リソースが存在することが保証され、カスタムのリソースロードメソッドを作成する必要がなくなります。

score 2 · Accepted Answer

LINQ to DataSetは、あなたにとって最適な方法のように思えます。

/ LINQ の前に .NET 3.5 を使用したことがない場合は、ご褒美があります。LINQ を使用すると、生の SQL を文字列リテラルで記述する必要がなくなり、より論理的な方法でクエリを作成できます。

とにかく、Access データベースで LINQ を使用するには、このリンクをチェックしてください - http://msdn.microsoft.com/en-us/library/bb386977.aspx

score 2 · Accepted Answer

SQL と Access の両方のアプリケーションを作成する必要がある場合は、いくつかの IDAL インターフェイス、共通の機能を実装した DALCommon を使用し、DALCommon から継承された個別の DALSql と DALAccess を、例外、トランザクション処理、セキュリティなどの特定のものとともに使用します。
以前は、ストアドプロシージャ名またはクエリをリソースファイルに保持していました。

score 1 · Accepted Answer

使用した 1 つの方法は、DB に接続するクラスとプロシージャを呼び出すメソッドを用意し、メソッドパラメータでプロシージャ名を指定することです。そのため、SQL コードはすべてプロシージャー内にあります。さまざまな戻り値の型にオーバーロードを使用します

class ConnectToSQL()
{
        //connectSql code (read from setting file i assume)

        XMLDataDocument runProcedure(string procedureName);
        int runProcedure(string procedureName);

        //etc....
}

score 1 · Accepted Answer

継承したコードで見たものを、どこに配置しないかを説明します。それはJavaでしたが、どの言語にも当てはまります

個々の SQL ステートメントを返す get メソッドを使用して、null に初期化された for SQL ステートメントの保護された静的メンバー変数を宣言した基本クラス
基本クラスのメンバー変数に割り当てる init メソッドを含む、サポートされている各データベースサーバーのサブクラス
基本クラスメソッドを使用して SQL ステートメントを取得するいくつかの DA クラス
正しいサブクラスオブジェクトを作成し、その init メソッドを呼び出す責任を持つアプリケーション起動クラス

また、なぜこれをやらないのかについても説明しません:-)

score 0 · Accepted Answer

上記の埋め込みソリューションは、SQL クエリにのような「where」原因がある場合は機能しない可能性がありますが、同じクエリの場合、PropertyID が読み込まれるため、次の実行には PropertyID='113' が必要です。

score 0 · Accepted Answer

カスタムレポートアプリの場合と同様に、インピーダンスの不一致を受け入れ、SQL を特に重視する必要がある場合があります。これらの場合、次のことをお勧めします。 SQL 文字列を含む各モジュールに対して、それらすべてを保持する単一の静的「SQL」クラスを作成します。一部の SQL 文字列にはパラメーターが必要になる可能性が高いため、一貫性を保ち、各文字列を独自の静的メソッドの背後に置きます。

私は時折のカスタムレポートアプリのためにこれを行うだけですが、それは常にうまく機能し、さわやかで解放感があります. そして、数か月後に戻って機能強化を行い、すべての SQL が 1 つの SQL.cs ファイルで待機していることを確認できるのは非常にうれしいことです。その 1 つのファイルを読み取るだけですべてが元に戻り、多くの場合、変更する必要があるのはこのファイルだけです。

このような場合、SQL をリソースや他の場所に隠す必要はないと思います。SQL が重要な場合は、SQL も重要です。興味深いことに、ますます多くの開発者が SQL と C# を自由に組み合わせています。このサイトを含めて、基本的にはそれが LINQ であるためです。

最後に、いつものように、SQL インジェクション攻撃を受けないようにしてください。特にユーザー入力が含まれる場合は、何らかのパラメーター化を使用していることと、文字列連結を使用していないことを確認してください。

score 0 · Accepted Answer

よろしくお願いします！SQL を QueryFirst .sql テンプレートに入れます。

埋め込みリソースとしてアプリに自動的にコンパイルされますが、気にする必要はありません。DBに接続された実際のSQLウィンドウで、テーブルと列の構文検証とインテリセンスを使用してそれを記述し、生成されたExecute()メソッドを介して、入力と結果のインテリセンスで使用します。

免責事項: QueryFirst を書きました。

c# - C# プロジェクトのどこに SQL ステートメントを配置しますか?

9 に答える 9

Related

Reference