場合によります。
すべてのルールに加えて、私は次のように言います。シンプルに保ち、同じことを繰り返さないでください。
いくつかのコメント:
Base エンティティがあり、Table Per Type メソッドを使用して、そこから約 10 個の異なる子エンティティを派生させているとします。
余談ですが、TPT のパフォーマンスが低いこと (少なくとも EF < 5 の場合) はご存知ですよね? テーブルが大きくなる可能性がある場合や、継承階層が深い場合 (派生エンティティから派生したエンティティなど) は特に注意が必要です。
最終的に、各子エンティティを個別のビューモデルにマップしたい
私の意見では、派生エンティティごとに ViewModel に適用される可能性のあるさまざまな検証ルールだけを考えれば、これは良い考えです。
エンティティの継承構造を模倣するために、「親」ビュー モデルを用意し、そこから子ビュー モデルを派生させる方がよいでしょうか?
私の意見では、エンティティの継承を模倣することは理由ではありません。ただし、たとえば、ベース モデル プロパティにビュー検証ルールがあり、それらがすべての派生エンティティに適用される場合、これらのルールを 1 か所 (ベース ViewModel など) に保持しないのはなぜですか。それ以外の場合は、派生したすべての ViewModel でそれらを繰り返す必要がありました。
この場合、各ビュー モデルには独自の CRUD 操作のセットが必要ですか?
派生エンティティが「フラット」(スカラー プロパティのみを持ち、ナビゲーション プロパティがない) の場合は、次のようなものだけが必要です。
Read: context.BaseEntities.OfType<T>().Where(...)...
Add: context.BaseEntities.Add(T entity);
Delete: context.BaseEntities.Remove(T entity);
Update: context.Entry(object o).State = EntityState.Modified;
これらのメソッドはすべて、ベース エンティティと派生エンティティに対して機能します。エンティティごとに個別にそのようなメソッドを作成する必要があるのはなぜですか? より複雑な状況では、個別のメソッドが必要になる場合があります。たとえば、派生エンティティ番号 7 に別のエンティティへのナビゲーション プロパティがあり、そのエンティティのビューで他のエンティティとの関係を変更できる場合などです。だから、それは依存します。すべて同じことを行うメソッドを複製することから始めるのではなく、後で特別な処理が必要であることがわかったときにリファクタリングします (プロジェクトの進行中のある時点で特別な処理が予想されることを最初から予測できる場合を除きます)。
基本的に各グリッドのビューモデルのID(キー)フィールドに基づいてJSONデータを返しています。また、すべてのグリッドにこの ID 列 (親エンティティの一部) があるため、すべてのグリッドに対してこれを処理する関数を 1 つだけ持つ必要がありますか?
リポジトリ/サービス側では、派生エンティティごとにスカラー プロパティのみが読み込まれる場合は、はい。派生エンティティ 7 のナビゲーション プロパティが必要な場合は、何か特別なもの (おそらくInclude
) が必要になる場合があります。エンティティごとに個別の ViewModel があるため、ViewModel へのデータの射影はすべてのエンティティに固有の場合があります。
リフレクションを使用する必要がありますか?
なんてこと?どうして?しないほうがいい。
親/子エンティティのポリモーフィック プロパティを利用する必要がありますか?
??? (<-これは「混乱した」絵文字であるはずです)