1

次のコードを使用して、ASP.NET DataGrid にバインドしています。私は次のものを持っていますが、うまくいきますが、これが最善のアプローチであるかどうか疑問に思っています。私が懸念していることは、接続を開く必要がなかったことと、DataReader を利用しなかったことです。これは私のコードビハインドページに書かれていることに注意してください。

             string strConn =  ConfigurationManager.ConnectionStrings["SQL1"].ConnectionString; 
             SqlDataSource DataSource1 = new SqlDataSource();  
             DataSource1.ConnectionString = strConn;
             DataSource1.SelectCommand = "SELECT * FROM tblTruck where LocId = @LocID ";     

             DataSource1.SelectParameters.Add(new Parameter("LocId", System.TypeCode.String, value));                 
             Grid1.DataSource = DataSource1.Select(DataSourceSelectArguments.Empty); 
             Grid1.Rebind();
4

2 に答える 2

1

この場合、DataSource コントロールは、接続を確立し、それを読み取り、戻り値を解析する内部ロジックを処理します。これ自体は非常に便利ですが、さらに制御が必要な場合は問題が発生します。

スタイル的には、SQL コードを UI にハードコーディングすることは決して良い考えではありませんが、連結する代わりにパラメーターを使用することは良いことです。

全体として、「最善のアプローチ」はありません。メンテナンス/変更、コードの脆弱性、パフォーマンス、信頼性、表示の複雑さなどの要因に基づいて、ソリューションを問題に合わせて調整する必要があります。

個人的にはデータソース コントロールは好きではありませんが、グリッドの構成に多くの時間を費やしたくない場合にグリッド作業に役立ちます。

SQLCommands は非常に高速で最適ですが、それらを使用するには大量のコードを作成して維持する必要があり、やや脆い場合があります。

DataAdapters/DataReaders/DataTables/DataSets は、SQLCommands よりもメンテナンスを書くのがいくぶん簡単ですが、メモリが煩雑になる可能性があり、多くの場合、正しく破棄されません。

Linq/ENF はどちらも記述と保守を容易にしますが、独自の SQL ではなく独自に生成された SQL でデバッグの問題が残る場合があり、一般的に実行が遅くなります (多くの場合、それほど重要ではありません)。

あなたの質問に答えるのに役立つことを願っています。

于 2012-10-29T19:50:09.973 に答える
0

コードを linq やエンティティ フレームワークなどの他の種類のプログラミングを使用するように進めたほうがよいと思います。プロジェクトがより高速で信頼性が高くなり、コーディングが減少するからです。

于 2012-10-29T20:10:20.967 に答える