私のデータベース設計では、テーブルの「クラスター」を持つ傾向があります。これらのクラスターは通常、1 つのアプリケーションまたは機能的に密接に関連するアプリケーションのグループをサポートします。多くの場合、これらのクラスターは、比較的少数の外部キーを介して相互に関連付けられます。これにより、ビジネス内の独立したアプリケーションを相互に統合することができます。
たとえば、「Foo」、「Bar」、「Baz」というアプリケーションがあり、それぞれに複数のテーブルがあるとします。テーブルとその外部キー参照のリストは次のとおりです。
- FooTableOne
- FooTableTwo -> FooTableOne
- BarTableOne -> FooTableTwo
- BarTableTwo -> BarTableone
- バズテーブルワン
- BazTableTwo -> FooTableTwo、BazTableOne
現在、LINQ-to-SQL を使用してこれらのテーブルにアクセスしています。クラスター (Foo、Bar、および Baz) ごとに個別のプロジェクトがあり、これらの各プロジェクトには、クラスター内のすべてのテーブルの .dbml があります。ここでの考え方は、クラスターを使用する各 (1 つ以上の) アプリケーションが、必要な LINQ クラスを含む共有ライブラリをインポートできるということです。
これは良い考えかもしれませんし、そうでないかもしれません。陪審 は まだ 出ていないようです。私が本当に疑問に思っているのは、異なるコンテキスト クラスに存在するにもかかわらず、別のクラスター内のクラスによって表現されるクラスター間の参照を持つことができるかどうかです。(より具体的には、Visual Studio でこの関係を作成する方法)。
例に戻ると、次のようにしたいと思います。
- プロジェクト・フー
- Foo.dbml
- FooDataContext
- FooTableOne
- FooTableOne.FooTableTwos
- FooTableTwo
- FooTableTwo.FooTableOne
- FooTableTwo.BarTableOnes (これはそれほど重要ではありません)
- FooTableTwo.BazTableTwos (これはそれほど重要ではありません)
- プロジェクトバー
- Bar.dbml
- BarDataContext
- バーテーブルワン
- BarTableOne.FooTableTwo
- BarTableOne.BarTableTwos
- BarTableTwo
- BarTableTwo.BarTableOne
- プロジェクトバズ
- Baz.dbml
- BazDataContext
- バズテーブルワン
- BazTableOne.BazTableTwos
- バズテーブルツー
- BazTableTwo.FooTableTwo
- BazTableTwo.BazTableOne
アウト オブ コンテキスト エンティティへの参照はすべてオブジェクトではなく単純な ID (int) であり、アウト オブ コンテキスト エンティティへのコレクションはまったく存在しません。これらのクラスに独自のメソッドを追加して、(コンテキストのインスタンスを指定して) 適切なルックアップを実行できることはわかっていますが、もう少し合理化して一貫性を持たせたいと考えています。
このコンテキスト/クラスターの分離により、アプリケーション間のモジュール性が得られることに注意してください。したがって、たとえば、Baz アプリケーションは Baz および Foo コンテキストのみをインポートする必要があり (Baz は Foo に依存しているため)、Bar はインポートしません。(これは、Foo に Bar エンティティのコレクションがないことを前提としていますが、これは問題ありません)。これは良いことですが、重要ではありません。LINQ/VS でこれが簡単にできない場合は、モジュール性を破棄して 1 つの大きなコンテキストを使用することを検討します。