1

3 層アーキテクチャでのデータベース アクセスについてサポートが必要です。私はasp.netとlinqでアプリケーションを開発しています。データベースには、少なくとも 9 つのマスター テーブルと合計 22 のテーブルがあります。データを管理するには、マスター テーブルごとにビューを使用する必要があります。

私の質問は、実行時または高速実行のためにどちらがより便利ですか?

  1. DataAccessLayerlinqを使用してページ レベルのクエリを使用するには (少なくとも 5 ～ 6 個のテーブルを持つ複数の結合を使用)
  2. ビューを使用して参照するにはDataAccessLayer
  3. すべてのクエリをストアド プロシージャに追加し、それらをすべてバインドします。

どれがベストプラクティスですか? ビューは実行時にページを重くしますか?

4

2 に答える 2

2

Linq2SQL クエリは通常、データベース上でパラメーター化されたクエリとして処理されます。

一般に、最新の RDBMS のインライン ステートメントよりもストアド プロシージャの方が効率的ですか? のようなパフォーマンスの違いを比較する SO に関する多くの議論があります。およびストアド プロシージャとパラメータ化されたクエリ

一般に、Linq2SQL のような ORM が提供する柔軟性の利点は、認識されているパフォーマンスの損失を上回るというのがコンセンサスだと思います。

IMO、LINQ2SQL は、ほとんどのデータ アクセス要件に対してジョブの 90% を問題なく実行します。PROC がより意味のある特別なニーズがある場合 (たとえば、本当にデータ集約型またはバッチ トランザクション)、1 つまたは 2 つ書くことができます。 procs とこれらをDataContext.

ただし、私たちが取り組んでいる間は、新しいプロジェクトで Linq2SQL を検討するつもりはありません。Entity Framework 4+ を見てみませんか? (OPは.NET 3.5を使用しています)

編集

テーブルの外部キーが正しく設定されている場合、基になるテーブルを Linq DBML にドラッグすると、ORM が基になるナビゲーションを処理するため、「手動で」結合する必要はほとんどないことがわかります。

例えば

var myUpvotes = Users.Where(u => v.UserId == someUser)
                     .Votes.Where(v => v.Upvote == true)
                     .Count();

必要な概念の 1 つは、Eager と Lazy loading です。これは間違いなく「結合」のパフォーマンスに影響します

于 2012-08-30T11:46:05.423 に答える
2

ベスト プラクティスはあなたの #1 になると思いますが、パフォーマンス ニーズがそれを要求する場合は、問題に対処するために #2 または #3 を持ち込むことについてオープン マインドを維持する必要があります。言い換えれば、できる限り #1 で実行しますが、必要な場合にのみコードのそれらの部分を改善するために #2 または #3 を使用してください。

ほとんどの場合、Linq2SQL / ORM を使用することによる生産性の向上と柔軟性が正しい選択になることがわかりました (そして @nonnb に同意します)。全体的な計画におけるSP - どちらかまたは両方の決定ではありません。必要に応じて両方を使用してください。一般に、SP の方が高速ですが、ほとんどの場合、アプリケーションに違いをもたらすには十分ではありません。ただし、適切なシナリオでは、本当に必要なときに大幅な改善を行うことができるため、SP はツールセットに保持する必要があります。

于 2012-08-30T12:25:19.613 に答える