0

したがって、この質問は少し難解に聞こえるかもしれませんが、何か「魔法のような」ことに気付き、ボンネットの下で起こっていることのパフォーマンスについて懸念を抱いています。TPC 設計を使用してエンティティを作成し、すべてのエンティティがルート ベース エンティティから (直接的または間接的に) 継承し、ルート ベース エンティティには、保存前にコードで生成されるグローバルに一意の識別子 (Guid など) が含まれているとします (つまり、データベースによって生成されます)。

次のコードは、対応するジェネリック型に関連するテーブルをクエリして、型指定された動的プロキシを返すことで機能することを期待しています (実際にそうしています)。

context.Set<ConcreteDerivedEntityClass>().Find(someGuid)

ただし、次のことを実行できることにも気付きました。

context.Set<BaseEntityClass>().Find(someGuid)

これは非常に優れており、適切な具象クラスの要求された Id に対して型指定された動的プロキシを魔法のように返します。Idがどの派生クラス/テーブルに属しているかをEFがどのように知っているのでしょうか? 一致するものが見つかるまで、知っているすべてのテーブル/エンティティタイプを調べますか (したがって、パフォーマンス上の懸念があります)?

4

1 に答える 1

0

継承テーブル/エンティティの主キーは、ベース テーブルを指す外部キーでもあります。

あとは、基本クラスから継承するクラスを確認するだけです。リレーションシップは実行時に静的であるため、すべての呼び出しでのリフレクションのパフォーマンスへの影響を回避するために、ロード時にメモリ内のリレーションシップもキャッシュする可能性があります。

あとは、子クラスの名前に一致するテーブルをクエリするだけです。継承が必要なため、これはクラスター化インデックスの seekになります。したがって、パフォーマンスの低下はありますが、取得した抽象化を考慮すると、取るに足らないものです。

編集：

既定のコードでは、最初に Table per Hierarchy (TPH) に頼ります。これは、Descriminator列にコード化されたエンティティ型を持つ 1 つの非正規化テーブルです。この場合、列は、結果を型キャストするエンティティを EF に通知します。

上記の TPC では、正しいテーブル マッピングを指定するために、DBContext に追加のコードが必要です。おそらくこれをメモリにキャッシュし、すでに上で説明したルーチンを実行します。

于 2013-10-25T19:18:08.877 に答える