エンティティフレームワークアーキテクチャのバインドされた（Db）コンテキスト

Question

私は、EF（http://www.pluralsight.com/training/Courses/TableOfContents/efarchitecture）で限定されたコンテキストの使用についてJulie Lermansのビデオを見てきました。 （POCOを使用して）実装する最良の方法を考えてください。私が見る2つのオプションは、すべてを定義する1つのedmxモデルを持ち、適切なエンティティを含めるためにDbContextを手作業で作成するか、各コンテキストに対して別々のedmxモデルを作成し、自動的に作成されたDbContextを使用することです。

いずれかのアイデアがありますか、どちらかの賛否両論がありますか？

IMHO： 単一のモデルでは、クラスが少なくて済み、多くのコードが再利用されます（ただし、これらのクラスは自動的に作成されるため、手動で複製される余分な機能にすぎません）。ある場所に多くのクラスがあり、特殊化が必要なクラスでは、それぞれ異なる名前が必要です。例えば。顧客、CustomerForFunctionalityX、CustomerForFunctionalityB。

別のモデルでは、プロパティを削除することが全く新しいエンティティである必要はないため、コンテキストに入るものをもっと厳しくすることができます。モデル間で違いがあってもCustomerオブジェクト）、それぞれのコンテキストは全く同じテーブルにマッピングされていても全く異なるエンティティを持ちます。あまりにも頻繁にそうでなければ、文脈が間違って定義されていることを意味する）。

Answer 1

どのような境界のあるコンテキストであるのか、どのような問題を解決しようとしているのかをお読みになることをお勧めします。制限されたコンテキストからdefinition：

モデルが適用されるコンテキストを明示的に定義します。チーム構成、アプリケーションの特定の部分での使用、コードベースやデータベーススキーマなどの物理的な表現の観点から、境界を明示的に設定します。モデルはこれらの範囲内で厳密に一貫性を保ちますが、外部の問題によって混乱したり混乱することはありません。

単一のEDMXモデルを持つことは、その明示的な境界に違反します。おそらく、異なるコンテキストのチームが同じEDMXモデルで動作するときに起こりうる摩擦を想像することができます。 しかし、あなたは、明示的な境界のコストとコンテキスト間の統合が高すぎると感じるかもしれません。 Shared Kernelを使用すると、EDMXモデルをコンテキスト間で共有することができます。

Answer 2

が、今、各コンテキストは、彼らが 全てであっても、ただこれは、あなたが実際には複数のコンテキスト（BC）を有界必要がないかもしれない兆候である

同じテーブルにマッピングする全く異なるエンティティを持っています。 BCの主な目標はfunctional cohesionであり、モデル間でBC間のチャタリング（カップリング）が大きくなると、単一のBCがより適切である可能性があります。異なるBCを分離する前に、モジュールをモジュール（.NETの名前空間）に分割してモデルを提供する方が良いか検討してください。詳しくはImplementing Domain-Driven Designをご覧ください。

多くの場合、さまざまなクエリの要件によって、実際には同じエンティティを表示するさまざまな方法が必要な複数のBCが再生されているように見えることがあります。これは全く異なるエンティティをすべて一緒に持つこととは非常に異なります。これを解決するにはread-model patternを使用することを検討してください。

Answer 3

私も境界のあるコンテキストを試していて、スキーマに（小さな？）問題があります。最初に、ドメインデータ用と監査タイプデータ用の2つのコンテキスト（エンティティ変更監査情報とプロセス情報の両方）を作成しました。 最初は、データベースが1つのコンテキストからテーブルを作成し、それを無視したことがわかりました。

public class BaseContext<TContext> : DbContext where TContext : DbContext 

という2つのコンテキストを導出すると、完全なデータベースが生成されているように見えますが、そのようには見えませんでした。

これを回避する方法の1つは、すべてのエンティティを参照するが、モデルに公開しない「マスター」コンテキストを作成することでした。これはうまくいきましたが、今dbにスキーマが少し問題があります。

私たちのサポート担当者がシステムのデバッグにSSMSを使用しているので、私はバインドされたコンテキストと同じ行に沿ってスキーマを変更することをお勧めしましたので、マスターコンテキスト（OnModelCreating方法は、マスターコンテキストを使用して）：

modelBuilder.Entity<Address>() 
      .HasKey(b => new {b.AddressId,b.EffectiveStartDate}) 
      .ToTable("Addresses", "Esr"); 

「Esr」はスキーマです。 ただし、バインドされたコンテキストでデータを書き込もうとすると、バインドされたコンテキストが「dbo」スキーマを使用していることを示すエラーが発生しています。この周りに道があると確信しています。私はこれがすべての努力の価値がないかもしれないと感じています。

確かに、有界のコンテキストはアプリケーションに対してより洗練された感覚を与えます。これは、全体的なアーキテクチャを仕様に近づけ、テストについて考えるときに役立つように、コードをドメイン構造に合わせて構造化するというアイデアが気に入っています。

一方、私の仲間のプログラマは、単一のモノリシックコンテキストに対してコーディングするときに正しいエンティティを選ぶのに問題が起こるでしょうか？

コンテキストの分離は、サポートまたはUATの分野で適用するとずっと便利です。これらの人々は、ビジネスプロセス全体の観点からアプリケーションを使用しなければなりません。

Answer 4

私たちは今、この正確な問題について議論しており、私もジュリーズのビデオと研究されているDDDを見てきました。データアクセスに作業ユニットを反映させたいが、複数のEDMXでテーブル名を使用できない問題が発生している。

テーブルCustomer、CustomerOrder、Order、OrderInventory、Itemがあるとします。 1つの画面では、顧客情報のみを表示したいので、私のEDMXにはCustomerが表示されます。今度は別のユースケースとして、顧客のすべての請求書があります。この使用例では、Customer、CustomerOrder、Order、OrderInventory、およびItemがあります。 複数のCLRタイプがEDMタイプ 'Customer'に一致するため、CLRタイプからEDMタイプへのマッピングが曖昧です。以前に見つかったCLRタイプ 'A.Customer'、新しく見つかったCLRタイプ 'B.Customer'。

このエラーメッセージはどうやって解決していますか？すべてのEDMXファイルに重複しているすべてのテーブルの名前を変更していますか？