すべてのテーブルを持つ1つのfatデータコンテキストクラスを持つか、より小さなクラスに分割し、潜在的に「単一テーブル」クラスを持つ方がよいでしょうか？LINQ to SQLクラス
組織的な観点からは、私はいくつかのデータ・コンテキスト（私はそれが実行可能であるとは思わない）で関係を分割すべきではないと感じます。しかし、一方では、無関係な単一のテーブルをクエリするために、そのファットクラスの完全な新しいインスタンスを作成することは過度のものだと私は考えています。
あなたはどう思いますか？
管理するテーブルの数にかかわらずデータコンテキストを構築するのは高価ではありません。したがって、1つ以上の別個のデータコンテキスト実装を持つかどうかを判断する際の基準ではありません。新しいデータコンテキストは、実際に使用するまで「空」になり、必要に応じてテーブルインスタンスが作成されます。
データコンテキストのインスタンスを高価にする理由は、異なるインスタンスへの変更を追跡するために同じインスタンスを繰り返し使用する場合です。たとえば、ASP.NETアプリケーションでキャッシュされたインスタンスをすべてのデータベース操作（今はそれはいいえ）。
作業単位のパターンでは、意図したとおりにデータコンテキストを使用する限り、必要なものをインスタンス化するだけで、クラス定義レベルで管理できるテーブルの数は関係ありません現在の作業単位。
私にとっては、データコンテキストは論理的にターゲットデータベースを表しているため、10または100のいずれであっても、そのデータベースにマップされているすべてのエンティティを表す必要があります。あるクラスでは、それはあなたが念頭に置いているものであれば、是非、違うクラスを持っていてください。
あなたが持っているテーブルの数によって異なります。 20歳以下の人は、私は個人的にそれを分けません。
必要に応じて、タスク、関係、目的別に分割することができます。
あなたまで、私は本当に言うでしょう。私が心に留めているのは、これを行うには最も保守的な方法ですか？それらを分割するかどうかを決めるときに。
ありがとうございました。 インスタンスのオーバーヘッドについてはわかりませんでした。だから、それをかなり上手くクリアしたと思います。実際、このプロジェクトでは、管理目的でDynamic Dataを、フロントエンドでMVCを使用しています。私は両方のために同じLINQ-to-SQLクラスを使用することになり、私はそれに固執するつもりだと思う。 –