33

ASP.net 3.5アプリケーションでLinqToSqlを完全に使用するには、DataContext クラスを作成する必要があります(これは通常、VS 2008のデザイナーを使用して行われます)。UIの観点からは、DataContextは、LinqToSqlを介して公開するデータベースのセクションの設計であり、LinqToSqlのORM機能のセットアップに不可欠です。

私の質問は、すべてのテーブルが外部キーを介して何らかの方法で相互接続されている大規模なデータベースを使用するプロジェクトを設定していることです。私の最初の傾向は、データベース全体をモデル化する1つの巨大なDataContextクラスを作成することです。そうすれば、理論的には(実際にこれが必要かどうかはわかりませんが)、LinqToSqlを介して生成された外部キー接続を使用して、コード内の関連オブジェクト間を簡単に移動したり、関連オブジェクトを挿入したりできます。

ただし、少し考えてみたところ、データベース内の特定の名前空間または論理的に相互に関連するセクションにそれぞれ関連する複数のDataContextクラスを作成する方が理にかなっていると考えています。私の主な懸念は、データベースの特定の領域に関連する個々の操作のために1つの巨大なDataContextクラスを常にインスタンス化して破棄すると、アプリケーションリソースに不要な負荷がかかることです。さらに、1つの大きなファイルよりも小さなDataContextファイルを作成および管理する方が簡単です。私が失うことは、LinqToSqlを介してナビゲートできないデータベースのいくつかの離れたセクションがあることです(関係のチェーンが実際のデータベースでそれらを接続している場合でも)。さらに、複数のDataContextに存在するテーブルクラスがいくつかあります。

1つの非常に大きなDataContextクラス(DB全体に対応)の代わりに(またはそれに加えて)複数のDataContext(DB名前空間に対応)が適切かどうかについての考えや経験はありますか?

4

5 に答える 5

28

私はジョンの答えに同意しません。DataContext(またはLinq to Entities ObjectContext)は、接続というよりも「作業単位」です。変更の追跡などを管理します。説明については、次のブログ投稿を参照してください。

LINQ toSQLDataContextの有効期間

このブログ投稿の4つの主要なポイントは、DataContextです。

  1. 「作業単位」アプローチに最適です
  2. 「ステートレス」サーバー操作用にも設計されています
  3. 長期間使用するようには設計されていません
  4. Should be used very carefully after
    any SumbitChanges() operation.
    

それを考慮すると、複数のDataContextを使用しても害はないと思います。実際、さまざまな種類の作業に対してさまざまなDataContextを作成すると、LinqToSqlの推進力がより使いやすく整理されたものになります。唯一の欠点は、sqlmetalを使用してdmblを自動生成できないことです。

于 2008-08-07T21:02:30.057 に答える
5

私は、レガシー DB で LINQ to SQL を後付けしながら、同じ質問について論争していました。私たちのデータベースはちょっと大げさ (150 テーブル) で、いくつか考えて実験した後、複数の DataContext を使用することにしました。これがアンチパターンと見なされるかどうかはまだわかりませんが、今のところ、管理しやすいものになっています。

于 2008-08-05T22:51:08.217 に答える
4

ジョンは正しいと思います。

「私の主な懸念は、データベースの特定の領域に関連する個々の操作のために1つの巨大なDataContextクラスを常にインスタンス化して破棄すると、アプリケーションリソースに不要な負荷がかかることです。」

その声明をどのように支持しますか?大規模なDataContextがパフォーマンスのボトルネックであることを示す実験は何ですか?複数のデータコンテキストを持つことは、複数のデータベースを持つことによく似ており、同様のシナリオで意味があります。つまり、ほとんどありません。複数のデータコンテキストを使用している場合は、どのオブジェクトがどのデータコンテキストに属しているかを追跡する必要があり、同じデータコンテキストにないオブジェクトを関連付けることはできません。それは実際の利益のために高価なデザインの匂いです。

@Evan「DataContext(またはLinq to Entities ObjectContext)は、接続というよりも「作業の単位」です。」そのため、複数のデータコンテキストを使用しないでください。一度に複数の「作業単位」が必要なのはなぜですか。

于 2008-08-27T01:11:45.710 に答える
2

LINQtoSQLおよびLINQtoEntitiesの私の経験では、DataContextはデータベースへの接続と同義です。したがって、複数のデータストアを使用する場合は、複数のDataContextを使用する必要があります。私の直感的な反応は、多数のテーブルを含むDataContextでの速度低下にはあまり気付かないだろうということです。ただし、そうした場合は、他のテーブルセットとは関係のないテーブルを分離し、複数のコンテキストを作成できるポイントで、データベースをいつでも論理的に分割できます。

于 2008-08-05T09:57:03.333 に答える