0


継承を使用せずに、次のモデルがあります:

質問クラス:

    public int QuestionId { get; set; }
    public string QuestionTitle { get; set; }
    public bool Required { get; set; }
    public int questionType { get; set; }
    [ScriptIgnore]
    public virtual ICollection<TextAnswer> TextAnswers { get; set; }
    [ScriptIgnore]
    public virtual ICollection<ParagraphAnswer> ParagraphAnswers { get; set; }
    [ScriptIgnore]
    public virtual ICollection<Choice> Choices { get; set; }
    [ScriptIgnore]
    public virtual ICollection<ChoiceAnswer> ChoiceAnswers { get; set; }

答えに継承を使用する必要がありますか?
あれは、

TextAnswer : Answer
ParagraphAnswer : Answer
ChoiceAnswer : Answer

Question クラスに ICollection が 1 つだけあるようにしますか?
あなたは私に何を提案しますか?

4

3 に答える 3

1

はい、これをモデル化する適切な方法は、継承を使用することです。

継承をテーブル (TPH、TPT) にマップする方法にはいくつかの選択肢があり、複雑なマルチレベルの階層では、パフォーマンスを監視する必要があることに注意してください。

于 2012-08-29T18:36:07.527 に答える
0

はい。それがJAVAの継承の利点です。このアプローチにより、コードの優れた設計を実現できます。

基本クラスのみが新しい ANSWER クラス用に拡張され、質問クラスに変更は必要ないため、コードはより少ないコード変更で新しい機能強化と拡張に対して開かれます。

于 2012-08-29T17:56:35.853 に答える
-2

継承とエンティティ フレームワークに関する私の経験はかなり貧弱です。特定のケースでは (ここではあまり詳しく説明しません)、EF によって生成されたクエリのサイズは 1Mb 程度でした.. (結果について話しているのではなく、テキストをクエリするだけです!)

最近 (約 6 か月) NHibernate を使い始めました。私の会社には、製品として開発されたソフトウェアがあります。これは、エンティティごとに少なくとも 3 ～ 4 レベルの継承を意味します。NHibernate はこれに非常にうまく対応しています。ぜひ試してみてください。

EFに関しては、継承を使用しないでください。このプロジェクトは十分に成熟していません。

// 反対票のため編集: 私は最初のリリースから Entity Framework を使用しており、Visual Studio 用のカスタム "カスタム ツール" を作成して EDMX ファイルからコードを生成するなどのハードコアな作業も含まれています。カスタム ジェネレーターは、ストアド プロシージャと適切な遅延読み込み (EF 1.0 で壊れていた) などのサポートを追加しました。

その後、EF 2.0 と大きな変更が行われました。私はいくつかのプロジェクトで EF を使用しました。そのうちの 1 つでは、すべてのエンティティが 1 つの基本クラスを持つという要件がありました。これは再びハードコアなハッキングであり、巨大なクエリ テキストが発生したケースです。私の答えに再び反対票を投じたい場合は、自由に投票してください。ただし、ケースがそれほど複雑ではないという理由だけで（基本クラスを持つことを複雑なケースと呼ぶことができる場合..）、EFが成熟していることを意味するものではありませんそして安定したORM。

于 2012-08-29T18:26:31.403 に答える