코드 첫 번째 POCO 디자인

Question

먼저 엔티티 프레임 워크 코드를 사용하여 데이터베이스를 만들고 데이터베이스/POCO 디자인에 문제가 있습니다. 내 문제는 상속에 있습니다.

내 시스템에는 Lecturer와 Student라는 두 가지 주요 사용자 역할이 있습니다. Id, Logon, Role (강사 또는 학생으로 식별), Forename 및 성을 포함하는 기본 User 클래스가 있습니다. 사용자가 강사 인 경우 태그 속성 (관계)이 관련되어 있습니다. 사용자가 학생 인 경우 1 년 및 학위 유형 속성이 있습니다.

두 가지 유형의 사용자가 모두 프로젝트를 만들 수 있습니다. 프로젝트에 제안자가 있습니다. 내가 원했던 것은 Project.Proposer에서 강사 나 학생 유형을 되 찾을 수있게하는 것이지만 그렇게 할 수는 없다. 나는 Project.Proposer가 Project 클래스에서 User (기본 클래스) 유형이어야하는지, 아니면 (코드를 먼저 사용하여) 인터페이스를 사용할 수 있는지 여부는 확실하지 않다.

사람들이 나에게 줄 수있는 지침이나 아이디어를 알려 주시면 감사하겠습니다. 많은 변형을 시도했지만 원하는 결과를 얻지 못하는 것 같습니다. 참고 : 사용자 클래스에 강사 및 학생 필드가 포함되지 않도록 중복 데이터가있는 사용자 클래스를 사용하지 않으려 고합니다.

Answer 1

이 방법은 EF4 CodeFirst에서 적절하게 수행하는 방법은 프로젝트에 유형의 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을 해당 클래스로 이동하는 것이 좋지만 권장하지는 않습니다. 이 프로젝트 클래스는 항상 별도로 처리해야하기 때문에 예를 들어 프로젝트 이름과 제안자를 검색 할 때 사용합니다. 기본 프로젝트 클래스에는 더 이상 제안자 속성이 없으므로 동일한 쿼리를 두 번해야합니다. 이 방법을 사용할 때 발생하는 문제를 설명 할 수 있기를 바랍니다.

---

다음 질문은 데이터가 데이터베이스에 저장되는 방식에 신경 쓰냐는 것입니다. 조언

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

한 단어 : 상속 클래스 이렇게 3 가지 방법이 있습니다입니다. 수백만 개의 레코드를 저장할 계획이 없다면 db에 실제로 저장되는 방법에 신경 쓰지 마십시오. Table per Hierarchy이 사용하기가 가장 쉽습니다. 특히 초기에는 특히 그렇습니다.

Answer 2

제안자로 User 클래스를 갖고 싶지 않은 경우 ProposedUserId과 같은 ID를 가진 경우 사용자 클래스를 쿼리하여 사용자 역할이 무엇인지 확인한 다음 필요한 세부 정보를 얻을 수 있습니다. 강의 또는 학생 테이블에서