エンティティフレームワークをプログラムで複数のテーブルに分割する

Question

私はEntity Framework 6 Code Firstを使用して、大きなPOCOモデルをデータベースに格納しています。モデルは1000sのプロパティを持ちます（lol **を要求しません）。つまり、複数のSQLテーブルに分割する必要があります（列の制限は1024です）。個別にプロパティを指定しなくても、これを行うにはどのような方法があります場合、私は思ったんだけど

modelBuilder.Entity<HugeEntity>.Map(m => 
{ 
    m.Properties(e => new { e.Prop1, e.Prop2 }); 
    m.ToTable("HugeEntity1"); 
}.Map(m => 
{ 
    m.Properties(e => new { e.Prop3, e.Prop4 }); 
    m.ToTable("HugeEntity2"); 
}; 

：私は、これは、通常そのような個々の列を指定することによって行われている知っています。理想的には、与えられた列の限界（つまり、1000）に基づいてエンティティを自動的に分割することができます。

標準的な方法がない場合でも、これを動作させるには最も簡単なハッキングは何ですか？モデルのプロパティは変更される可能性がありますので、複数の場所で完全にリストすることは避けてください。

アドバイスありがとうございます。

** CONTEXT：ドメインモデルで、特定のWebページでキャプチャする必要があるユーザー入力データを表します。 WebAPIにも公開されています。私のチームはキーとバリューのペアのアプローチを検討しましたが、WebAPIにヒットした将来のBIアプリケーションがデータを消費するのが難しくなると判断しました。

Answer 1

これを行う方法がわかりました。私はLinq式と "動的"キーワードを使用しなければなりませんでした。

private static void SplitIntoTables<T>(DbModelBuilder modelBuilder, IReadOnlyCollection<PropertyInfo> properties, int columnLimit) where T : class 
    { 
     var numberOfTables = Math.Ceiling((properties.Count + (double)columnLimit/2)/columnLimit); 
     var paramExp = Expression.Parameter(typeof(T)); 

     var tableIndex = 0; 
     foreach (var tableGroup in properties.GroupBy(p => p.Name.GetHashCode() % numberOfTables)) 
     { 
      var expressions = tableGroup.Select(p => Expression.Lambda(
       typeof(Func<,>).MakeGenericType(typeof(T), p.PropertyType), 
       Expression.Property(paramExp, p), paramExp)); 

      modelBuilder.Entity<T>().Map(m => 
      { 
       foreach (var exp in expressions) 
       { 
        m.Property((dynamic) exp); 
       } 
       m.ToTable($"{typeof(T).Name}_{++tableIndex}"); 
      }); 
     } 
    } 

Answer 2

あなたは私たちに「尋ねないでください」と言います。しかし、あなたの最大の問題は、あなた自身にそれを言っているということです。あなたのモデルが50以上のフィールドを持つようになると、何が起こっているのかを尋ねる必要があります。私は、息を飲んでコンピューティングのいくつかのより抽象的な概念を再訪する価値がないのだろうかと思います。私はDatabase Normalizationから始めます。 1Kの動的プロパティは、あなたがこれを必然的に必要としていることを私に伝えます。

ところで、「データベース正規化」の概念は、SQLデータベースそのものに固有のものではありません。できるだけ同じ場所でPOCOモデルを正規化する必要があります。確かに、OO言語にはいくつかの非リレーショナル概念があります。しかし、あなたが描いている極端な言い訳はありません。

もう1つのパラダイムはDomain Driven Designです。私は自分でそれほど流暢ではないので、私はあなたがそこから始めなければならないと言っているわけではありません。しかし、私がそれを実装する際の初めから、学習曲線は価値があったと言いたいと思います。

私は念頭に置かないでください。私は自分のテーブルを自分で最高の普通の形にしているわけではありません。しかし私は、私がしていない分野では、頭痛が強いことを伝えます。