Entity Framework Coreの具象タイプごとのテーブル
エンティティフレームワーク6（EF6）からエンティティフレームワークコア2.0（EF-Core）にコードを移植しようとして、行き止まりに遭遇しました。
私のEF6コードには、すべてのRecordタイプの基本プロパティとメソッドを定義するRecordという基本クラスがあります。この基本クラスは、すべての異なるタイプのレコードに共通の機能とプロパティを提供します。
ベースRecordクラスから派生するレコードには、さまざまなタイプのレコードがあります。これらの各Recordsには、そのタイプのレコードに固有の追加のプロパティがあります。たとえば、CustomerComplaintクラスとTrainingRecordクラスがあり、どちらもRecordクラスから派生しています。ご想像のとおり、2つのRecordsのプロパティは大きく異なります。ただし、どちらも編集、送信、権限チェックなどの共通機能を共有しています。
私の問題は、EF-Coreが具象タイプごとの継承階層のテーブル（たとえば、レコードのタイプごとに個別のテーブル）をサポートしていないことです。現在、EF-Core 継承階層をTable per Hierarchyスキームにマッピングすることのみをサポートしています （たとえば、すべてのサブクラスのプロパティとサブクラスを区別するための識別子の値を持つ単一のテーブル）。十数種類のレコードがある場合、階層ごとのテーブルスキームでは、データベース内のテーブルが大雑把になります。それは私のすべてのレコードサブクラスのすべてのプロパティの列を持つ単一のテーブルを作成します！
この問題の回避策を実装するにはどうすればよいですか？私が考えた1つの解決策は、階層をインターフェースとサービスに分解することです。これらのプロパティを使用してインターフェイスを定義することで、共通のプロパティを共有できます。また、インターフェイスを実装するオブジェクトでのみ動作するサービスクラスにコードを移動して、共通のコードを共有できます。
もちろん、テーブル内の列が多すぎる可能性もありますが、これが問題である主な理由は、すべての列を同時に処理しようとするときです。これは、独自のSQLステートメントを作成する場合に問題になります。
Entity Frameworkは実際にはTable-Per-Hierarchyの処理に非常に優れています。コードでは、特定のサブクラスによって実際に使用されている列のみが表示されます。したがって、SQLを手動で作成した場合ほど大きな問題にはなりません。コードでは、サブクラスごとに異なるテーブルがあるように見えます。
テーブルが大きすぎる場合は、独自のソリューションが適切です。そして、私はそれについて行く方法になるでしょう。
私は試していませんが、各サブクラスに同じベースクラスを継承させることはできますが、DbSet<>そのベースクラスの場合、Entity FrameworkはTable-Per-Hierarchyではなく別のテーブルを使用します。