2017-01-09 19 views
-1

今、私は、データのようなはどのように私はasp.net MVCプロジェクトで私のSQLクエリスクリプトを管理することができます

コードを処理するために、Dapperのを使用して上記のように、多くのSQLスクリプトを作成します

using(var connection = new SqlConnection(ConfigurationManager.AppSettings["MyConnectString"]) 
{ 
    var sql = string.Format(
     @"SELECT [Column1] 
      FROM [MyTable] 
      WHERE [Column3] > {0} 
       AND [Column4] < {1}" 
     , myValue1 
     , myValue2 
    ); 
    var result = connection.Query<long>(sql).ToList(); 
} 

マイプロジェクトを。

は私が

は、その後、私はファイルからスクリプトを読み込むことができます(...より良いかもしれないQueryAccount.config、QueryOrder.config、(xml形式)...等)のファイルにスクリプトを書きたいと思います。..私が欲しいもの。


はその後、私は、ファイルに同じクラス を書き、ファイルに私のスクリプトを記述しています。 (。例えば私はProduct.config内のすべてのクエリ商品のスクリプトを書き、Order.config内のすべてのクエリ注文スクリプトは)その後、私は次のように

var cmd = MyCommandManager.GetScript("QueryProduct"); 
cmd.SetParam("@ProductId", 123); 
cmd.SetParam("@InvoicingDate", DateTime.Now(-7)) 
... 

スクリプトなどのファイルで使用 :

SELECT [ProductName] 
FROM [Product] 
WHERE [ProductId] = @ProductId 
    AND [InvoicingDate] = @InvoicingDate 
+4

これをしないでください - あなたはSQLインジェクション攻撃を求めています! –

+3

なぜあなたはそれを望んでいますか? –

+0

スクリプトごとにストア・プロシージャを作成し、パラメータを指定してストア・プロシージャをコールするだけです。それはSQLインジェクションを避けるでしょう。 –

答えて

1

あなたの場合データベースにフルアクセスして、Stored Procedureを実装してSQLテキストを格納しようとすることができます。あなたがする必要があるだろうすべては、Dapperのクエリでストアドプロシージャ名の参照であるとのStoredProcedureにコマンドタイプを設定し、あなたがそうのように、行ってもいいでしょう。

using(var cn = new SqlConnection("MyConnectionString")) 
{ 
    cn.Open(); 
    return cn.Query<MyModel>("MyProcName", new { Parameter1 = myValue1, Parameter2 = myValue2 }, commandType: CommandType.StoredProcedure); 
} 

SQL偶然にを使用する代わりにに値を注入しますSQLインジェクション攻撃を防ぐので、クエリは非常に賢いことです。クエリを再フォーマットすると次のようになります。

@"SELECT [Column1] 
    FROM [MyTable] 
    WHERE [Column3] > @Parameter1 
    AND [Column4] < @Parameter2" 

パラメータ名が上記のdapper呼び出しと一致することに注意してください。しかし、私はストアドプロシージャを使用しないときは、私は通常、私の "ストレージ"のクエリを参照するクラスの先頭にprivate const stringを作成します。各クラスは、通常は1つのクエリを持っているので、私はCommand/Query Pattern like this oneに加入

public class QueryClass 
{ 
    private const string query = "SELECT * FROM Table1"; 

    public IEnumerable<MyModel> CallQuery() 
    { 
     // Dapper Query Details 
    } 
} 

ので、私は、クエリの保存に問題があることはありません。あなたは、コマンド/クエリパターンを好きなら

EDIT

は、私はそれがこのようなパターンの素敵な実装であるとして、あなたはMediatRをチェックアウトをお勧めします。

SECOND EDIT

私はあなたが私はその反対をアドバイスしたいことができますがあれば、設定ファイルのいくつかの並べ替えにSQLクエリを追加することでやろうとしているものを参照してください。私の最後の仕事では、すべてのSQLクエリは、アプリケーションにコンパイルされたXMLファイルに格納されていました。それはクエリを管理する効果的な方法のように思えましたが、アプリケーションがいくつかのSQL XMLファイルになってしまえば、いくつかのXMLファイルでどこにクエリーが重複しているのか分かりませんでした。私たちはまた、実行時まで捕らえられなかったtypoやその他のXML構造エラーに多くの問題を抱えていましたが、必ずしも間違いがないように任意の文字列に入力できます。それは混乱で終わり、解決するよりも多くの問題を引き起こします。

SQLクエリテキストをできるだけ必要とするコードに近いものにする方がよいと思います。名前空間とクエリオブジェクトの整理について賢明であれば、開発者がクエリを簡単に見つけることができますインテリセンスを介して。

0

ダウンワードを無視します。 SQLは常にそれ自身のファイルになければなりません。これらのファイルの拡張子は、.configではなく.sqlでなければなりません。したがって、それらはVS SQLエディタで編集され、本当に快適です。あなたは1つのクエリごとに1つのファイルが必要だと思います。同じファイル内の異なるクエリをグループ化することでは何も得られません。これらのファイルを消費する.csファイルの隣に置くこと、あなたが一緒に開いているファイルをグループ化すること、そして1日一緒に削除したいと思うファイルを提唱したいと思います。

作成したら、ソリューションエクスプローラで.sqlを右クリックし、[プロパティ] - [ビルドアクション] - > [埋め込みリソース]をクリックします。次に、MyCommandManager.GetScript()メソッドで、GetManifestResourceStream()を使用してクエリテキストにアクセスします。ストアドプロシージャと比較すると、クエリが呼び出しコードでコンパイルされるという大きな利点があります。したがって、ストアドプロシージャのバージョンとアプリケーションのバージョンを同期させることを心配する必要はありません。

このすべてが多くの作業のように思われる場合は、ちょっとです。それで誰もそれをしない理由ですが、彼らは:QueryFirstをつかんでください。それはあなたのために、そして他にもたくさんあります。免責事項:私はQueryFirstを書いた。

関連する問題