4

古いアプリケーションを WebForms から MVC に移植する作業を行っています。そのプロセスの一部では、既存のデータ層を引き裂き、ロジックをストアド プロシージャからコードに移動しています。最初は基本的な C# SQL 関数 (System.Data.SqlClient) しか扱っていなかったので、SQL ステートメントを文字列として受け取って実行する軽量の疑似 ORM ( PetaPoco ) を使用しました。動的クエリの構築は、SQL でもほぼ同じように機能します。追加のコードを追加および削除する多くの条件 (平均クエリには約 30 個のフィルターがあります)。

そこで、少し調べてみると、いくつかの選択肢が見つかりました。

  • 必要に応じてクエリの一部を追加する一連の文字列と条件。特にクエリが複雑になると、本当に厄介であり、より良い解決策が存在する場合、私が追求したいものではありません.
  • L2E を使用した一連の条件。よりエレガントに見えますが、私がテストした L2E は全体的に肥大化しすぎており、ひどい経験でした。L2Sでも同じことができますか？もしそうなら、L2S は今後 5 ～ 10 年間存続しますか?
  • PredicateBuilderを使用します。これについてはまだ調べていますが、L2S に関する同じ質問です。
  • 編集: 既存のストアド プロシージャ モデルに固執することもできますが、とにかくそれらを書き直す必要があるため、他のオプションを見て損をすることはありません。

そこに他のオプションはありますか？言及された方法のいずれかについて経験を積んだ人は誰でも参加できますか?

4

3 に答える 3

3

LLBLGenを見てみます。それが生成するコードは非常に優れており、カスタマイズ可能です。また、クエリに役立つ可能性のある堅牢なlinqプロバイダーも提供します。私はそれをいくつかの大きなプロジェクトに使用し、とても幸せでした。

http://www.llblgen.com/

于 2011-06-01T00:20:01.480 に答える
1

本当の答えではありませんが、コメントするには長すぎます:

「SQL の連結部分」メソッドを使用して中規模の Web アプリを構築しましたが、現在、L2E を使用して同様の作業を行っています。

自制心があれば、concatenate-pices-of-sql メソッドはそれほど悪くないことがわかりました。もちろん、パラメーター化されたクエリを使用します。ユーザー入力を直接 SQL に貼り付けようとしないでください。

しかし、私はゆっくりと L2E メソッドの評価を高めてきました。WHERE X IN (...)これにより、型の安全性が確保されますが、コンストラクトなど、SQL で行う方法から「逆方向」に行う必要があるものもあります。しかし、これまでのところ、L2E が処理できないものにヒットしたことはありません。

L2E アプローチは、他の人が大きく関与することで維持するのが少し簡単になると思います。

L2E の「肥大化」が問題となる実際の使用例はありますか? それとも、フレームワークが舞台裏でやりすぎていると感じる一般的な倦怠感ですか?

私は間違いなく最初はそのような感覚を持っていました (わかりました、今でもそうです)、確かに生成された SQL を読むのは好きではありません (特に、以前のプロジェクトの手書きの SQL と比較して)。実際に必要なときに DB をヒットします。

もう 1 つの懸念事項は、使用している DB と、その L2E バインディングがどの程度最新のものであるかです。SQL Server を使用している場合は問題ありません。ただし、MySql はもっと不安定かもしれません。L2E の滑らかさの一部は、VStudio との優れた統合と、DB からエンティティ モデルを自動的に構築する VStudio の機能に由来します。非 MS DB バックエンドのサポートがどれほど優れているかはわかりません。

于 2011-06-01T00:45:16.993 に答える
1

私の意見では、特に複雑なクエリに関しては、L2S も L2E も効率的な SQL コードを生成できません。比較的単純な場合でも、2 つの方法のいずれかを使用してクエリを生成すると、効率の悪い SQL コードが生成されます。例を次に示します。

そうは言っても、SQL Server を使用している場合、L2E は任意のデータベースを処理するためのものであるため、L2S の方が適しています。そのため、L2E は非効率的な SQL コードを生成します。また、L2S も L2E も tempDB を利用しない、つまり一時テーブルまたはテーブル変数または CTE を生成しないことにも注意してください。

ストアド プロシージャを書き直して、可能な限り最適化し、単純なクエリに L2S/L2E を使用します。これにより、サーバーへのラウンドトリップが 1 回発生します (これはできるだけ低くする必要があります)。 SQL Server が使用する実行計画が最も効率的です (つまり、インデックスなどを使用します)。

ハサナイン

于 2011-06-01T01:23:50.317 に答える