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名前空間に対応)が適切かどうかについての考えや経験はありますか?