5

EF での境界付けられたコンテキストの使用に関する Julie Lermans のビデオ (http://www.pluralsight.com/training/Courses/TableOfContents/efarchitecture) を見たところです。 . 私が見る 2 つのオプションは、すべてを定義する 1 つの edmx モデルを用意してから、DbContext を手作りして適切なエンティティを含めるか、コンテキストごとに個別の edmx モデルを用意し、自動的に作成された DbContext を使用することです。

どちらが最適か、またはどちらかの長所/短所についてのアイデアはありますか?

IMHO: 単一のモデルの場合、クラスが大幅に減り、コードの再利用が大幅に増えます (ただし、これらのクラスは自動的に作成されるため、実際には手動で複製される追加機能のみになります)。クラスを 1 か所にまとめ、特殊化する必要があるクラスについては、それぞれに異なる名前を付ける必要があります。例: Customer、CustomerForFunctionalityX、CustomerForFunctionalityB。

個別のモデルを使用すると、プロパティの削除が完全に新しいエンティティである必要がないため、コンテキストに入る内容をより厳密にすることができます。また、必要に応じてすべてに名前を付けることができます (つまり、すべてのモデルは Customer オブジェクトを使用できます。モデル間で異なります)、しかし、すべてが同じテーブルにマッピングされているだけであっても、各コンテキストには完全に異なるエンティティが含まれるようになりました.コンテキストが間違って定義されていることを意味します)。

4

4 に答える 4

1

私たちは今この正確な問題について話し合っており、私もジュリーズのビデオを見たり、DDDを調べたりしました。データアクセスに作業単位を反映させたいのですが、テーブル名を複数のEDMXで使用できないという問題が発生しています。

たとえば、Customer、CustomerOrder、Order、OrderInventory、Itemのテーブルがあるとします。1つの画面に顧客情報を表示したいので、そのためのEDMXには顧客しかありません。もう1つのユースケースは、顧客のすべての請求書です。このユースケースには、Customer、CustomerOrder、Order、OrderInventory、およびItemがあります。この例外が発生します。複数のCLRタイプがEDMタイプ「Customer」と一致するため、CLRタイプからEDMタイプへのマッピングがあいまいです。以前に見つかったCLRタイプ'A.Customer'、新しく見つかったCLRタイプ'B.Customer'。

このエラーメッセージをどのように回避していますか？すべてのEDMXファイルに複製されているすべてのテーブルの名前を変更していますか？

于 2013-03-21T18:45:13.830 に答える
1

私も境界付けられたコンテキストを試していますが、スキーマに関する (小さな?) 問題に遭遇しました。最初に 2 つのコンテキストを作成しました。1 つはドメイン データ用、もう 1 つは監査タイプ データ (エンティティ変更監査情報とプロセス情報の両方) 用です。最初に、データベースが 1 つのコンテキストからのみテーブルを作成し、もう 1 つのコンテキストを無視していることに気付きました。基本コンテキストから 2 つのコンテキストを導出すると、

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

完全なデータベースを生成しますが、そうではないようです。

これを回避する 1 つの方法は、すべてのエンティティを参照する "マスター" コンテキストを作成することでしたが、モデルには公開しませんでした。これは問題なく機能しましたが、db スキーマに小さな問題があります。

私たちのサポート担当者は SSMS を使用してシステムをデバッグしているので、境界付けられたコンテキストと同じようにスキーマを変更するのは良い考えだと思ったので、マスター コンテキストでスキーマを指定しました (マスターで OnModelCreating() メソッドをオーバーライドする)環境）：

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

「Esr」はスキーマです。ただし、境界付けられたコンテキストでデータを書き込もうとすると、境界付けられたコンテキストが「dbo」スキーマを使用していることを示すエラーが発生します。これを回避する方法があると確信しています。私はこれがすべての努力の価値がないかもしれないというしつこい気持ちを持っています.

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

一方、私の仲間のプログラマーは、単一のモノリシック コンテキストに対してコーディングするときに、適切なエンティティを選択するのに苦労するでしょうか?

コンテキストの分離は、サポートまたは UAT の領域に適用すると、はるかに役立ちます。これらの人々は、ビジネス プロセス全体の観点からアプリケーションを操作する必要があります。

于 2012-10-29T01:55:29.457 に答える
0

制限されたコンテキストとは何か、そしてそれらが解決しようとしている問題について読んでおくことをお勧めします。境界コンテキスト定義から：

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

単一のEDMXモデルがあると、その明示的な境界に違反します。おそらく、異なるコンテキストのチームが同じEDMXモデルで作業するときに発生する可能性のある摩擦を想像することができます。ただし、あなたの場合、その明示的な境界とコンテキスト間の統合のコストが高すぎると感じるかもしれません。共有カーネルを使用すると、コンテキスト間でEDMXモデルを共有できます。

于 2012-10-25T11:59:02.537 に答える
0

しかし今では、すべてが同じテーブルにマッピングされているだけでも、各コンテキストにはまったく異なるエンティティがあります

これは、複数の境界コンテキスト（BC）が実際には必要ない可能性があることを示しています。BCの主な目標は機能の凝集度であり、モデルがBC間で大量のチャタリング（つまり結合）を起こす場合は、単一のBCの方が適切であることを示している可能性があります。さまざまなBCを分離する前に、モジュール（.NETの名前空間）にパーティション化することでモデルがより適切に提供されるかどうかを検討してください。詳細については、ドメイン駆動設計の実装をご覧ください。

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

于 2012-10-25T16:50:23.493 に答える