コードファーストPOCOデザイン

Question

まず、エンティティフレームワークコードを使用してデータベースを作成していますが、データベース/ POCOデザインに関するいくつかの問題があります。私の問題は相続にあります。

私のシステムには、LecturerとStudentの2つの主なユーザーロールがあります。私はID、ログオン、役割（講師か学生かを識別する）、姓と姓を含む基本Userクラスを持っています。ユーザーが講師である場合、それらに関連付けられたタグプロパティ（関係）もあります。ユーザーが学生の場合は、年と学位タイプのプロパティがあります。

両方のタイプのユーザーがプロジェクトを作成できます。プロジェクトには提案者がいます。私が欲しいのは、Project.Proposerから講師や学生のタイプを返すことですが、私はそうすることはできません。私はProject.Proposerが、プロジェクトクラスのUser（基本クラス）でなければならないのかどうか、私は（コードを最初に）使うことができるのかどうかも分かりません。

人々が私に与える可能性のある指導やアイデアに感謝します。私は多くのバリエーションを試しましたが、望みの結果を与えるものはありません。注：私は冗長なデータを持つユーザークラスを避けようとしているので、ユーザークラスに講師と生徒のフィールドが含まれないようにしています。

Answer 1

これは、EF4 CodeFirstで正しく実行される方法は、プロジェクトでタイプUserのProposerプロパティを持つことです。

プロジェクトを取得した後、提案者は正しいタイプを持ちますが、値はUserとなります。

// project is a Project instance  
if (project.Proposer is Lecturer) 
{ 
    // do something 
} else if (project.Proposer is Student) 
{ 
    // do something else 
} 

これは私が示唆しているデータ構造である：実際の実際の型は、あなたがこのようなisキーワードを使用することができているかを把握するために

public class Tag 
{ 
    [Key] 
    public int ID { get; set; } 
} 

public abstract class User 
{ 
    [Key] 
    public int ID { get; set; } 
    public string Forename { get; set; }   
    public string Surename { get; set; } 
} 

public class Lecturer : User 
{ 
    public IEnumerable<Tag> Forename { get; set; } 
} 


public class Student : User 
{ 
    public IEnumerable<Tag> Forename { get; set; } 
} 

public class Project 
{ 
    [Key] 
    public int ID { get; set; } 

    public User Proposer { get; set; } 
} 

はこれを構造化する他の方法がありますが、 LecturerProjectStudentProjectなどのクラスを使用してプロジェクトの階層を導入し、正しいタイプのProposerをこれらのクラスに移動するようにしてください。ただし、これはお勧めしません。これらのプロジェクトクラスは常に個別に処理する必要があるためです。たとえば、プロジェクトの名前と提案者を取得する場合などです。基本プロジェクトクラスにはもうプロポーザープロパティがないので、同じクエリを2回実行する必要があります。このアプローチを使用する際に発生する問題を説明できることを願っています。

---

次の質問には、データがどのようにdbに保存されているか気になりますか？アドバイスの

• Table per Hierarchy
• Table per Type
• Table per Concrete class

一言：継承したクラスのためにこれを行うための3つの方法がありますので。何百万ものレコードを格納する予定がない場合は、実際にdbに格納される方法に気を付けないでください。 Table per Hierarchyがはるかに使い勝手が良く、特に最初の段階では、これがデフォルトです。

Answer 2

提案者としてUserクラスを使用したくない場合は、そのIDを持つProposedUserIdのようなプロパティを持つと、ユーザークラスの内容を照会して必要な詳細を取得できます講義または生徒のテーブルのいずれか