Entity Frameworkで、ビューモデルのディスクリミネータ列が作成されるのはなぜですか？

Question

私はちょうどTable per Type/TPTと弁別者欄のかなりの記事を読んだことがありますが、私は自分の状況では賢明ではありません。

例を挙げる：Fooというモデルを持つMVCアプリケーションがあります。これにはBarという1つのプロパティがあり、それは他の場所に1対多として格納されています。

私はこのアプリを使用している唯一の人です。私はそれに多くの時間を費やしたくなかったので、Barのリストに項目を追加するための最も簡単な方法が必要でした。このため、という新しいクラスを作成しました。これはFooから派生し、BarTempという文字列プロパティを持ちました。

基本的な考え方は、標準のテキストフィールドに111, 222 , 333,444を入力し、編集/作成コントローラに空白を取り除き、コンマのリストに分割できるということです。

私が理解できないことは、ビューモデルは決してEFに書き込まれないため、なぜディスクリミネータ列を作成するのかということです。

マイグレーションを踏み台にしようとしたときのように、それはBarTempをDBに追加しようとしました。

私は同じタイプの新しいタイプを作成しましたが、派生するのではなく、FooとBarTempというプロパティが期待通りに機能していますが、まだ何が起こっておらず、もっと。

Answer 1

これは、EntityFrameworkが階層を解析するためです。

context.Bars.Add(new BarTemp()); 

以上を検出するために行うことができますEntityFrameworkは何もありません：あなたの現在のコードは、これまでBarTempを保存していないからといって、明示的に書き込みからあなたを止めるものは何もありません。したがって、安全であり、エンティティから継承する場合、サブクラスはでもがエンティティになることを前提としています。これは正しい仮定です。ビューモデルをエンティティから継承することは避けてください。それらはプロパティでもありません。私は本当に確信していませんどのようにあなたの現在のコードを設定しました、しかし、クラスは完全に別個でなければなりません。たとえば、次のようになります。

class BarTemp 
{ 
    public string BarId { get; set; } 
    public string Foos { get; set; } 
} 

class Bar 
{ 
    public string BarId { get; set; } 
    public ICollection<Foo> Foos { get; set; } 
} 
class Foo 
{ 
    public string Id { get; set; } 
    public Bar Bar { get; set; 
} 

ビューモデルはエンティティについて何も知らず、エンティティはビューモデルについて何も知らない必要があります。入力を受け入れるコードは、ビューモデルをエンティティに変換する作業を行う必要があります。例えば： - それは非常に非効率的だ -

private void Update(BarTemp barTemp) 
{ 
    var bar = context.Bars.GetById(barTemp.BarId); 
    foreach (var foo in barTemp.Foos.Split(",")) 
    { 
     var foo = context.Foos.GetById(foo); 
     bar.Foos.Add(foo); 
    } 
    context.Save(); 
} 

は良いコードの例として、上記を取ってはいけないが、それはあなたの変換が行われるべきである、とエンティティとビューを維持するためにどのようにどこの一例を示すべきモデルは別々です。