如何模擬這種關係？

Question

首先我明確表示，我沒有使用任何OR映射器框架來解決這個問題，因爲我需要從頭開始理解模型。

好的。讓我們來看看錶的設計：

場 - 表

------------------ 
ID | CourseName 
------------------ 
1 | C++ 
2 | Java 
------------------ 

教師 - 表

----------------------- 
ID | TeacherName 
----------------------- 
1 | Professor X 
2 | Professor Y 
----------------------- 

CourseTeacher - 表

--------------------------------------------- 
ID | CourseID | TeacherID | ClassTime 
--------------------------------------------- 
1 | 1  |  1  | Monday 10:55 
2 | 1  |  2  | Thursday 10:55 
3 | 2  |  1  | Tuesday 11:45 
4 | 2  |  2  | Wednesday 11:45 
--------------------------------------------- 

我應該如何設計我的C＃類？

可以有另一個問題像是：

用戶 - 表

------------------ 
ID | UserName 
------------------ 
1 | a 
2 | b 
------------------ 

角色 - 表

----------------------- 
ID | RoleName 
----------------------- 
1 | c 
2 | d 
----------------------- 

的UserRole - 表

--------------------------------------------- 
ID | UserID | RoleID | Remarks 
--------------------------------------------- 
1 | 1  |  1  | xy 
2 | 1  |  2  | yz 
3 | 2  |  1  | zx 
4 | 2  |  2  | xx 
--------------------------------------------- 

Answer 1

我thinkt你實際上有一個隱藏在那裏的第三個概念：一個ClassSession或類似的東西。每個ClassSession都有一個Teacher，一個課程和一個DateTime。

public class ClassSession 
{ 
    public Teacher Teacher { get; set; } 

    public Course Course { get; set; } 

    public DateTime Time { get; set; } 
} 

Answer 2

一般情況下，當你有一個多到許多在你的領域模型的關係，在你的代碼的訪問模式，要麼是從M2M的或從另一面......

例如如果你有一個包含人的結構，每個人都在你的零售店進行了大量的採購，你可能通常希望訪問這些交易，而不是通過產品。換句話說，你可能更想知道某個特定的人購買了哪些產品，而不知道人們購買了哪種產品。所以在這個例子中，您只需讓每個人類都包含一個屬性，這是一個產品集合。沒有必要通過Product類訪問Person類。

另一個例如如果你有一個包含人的結構，每個人都會訂閱一些雜誌。

現在，如果您是出版商，您可能通常希望通過雜誌訪問這些交易，而不是通過該人。換句話說，你會更多地想知道人們訂閱特定雜誌的內容，而不是特定人員訂閱的雜誌。所以在這個例子中，你會在Magazine類中放置一個Subscribers集合屬性。

Answer 3

我的示例：

interface ICourse 
{ 
    string Name { get; set; } 
} 

interface ITeacher 
{ 
    string Name { get; set; } 
} 

interface IClassSession 
{ 
    ICourse Course { get; set; } 
    ITeacher Teacher { get; set; } 
    DateTime Scheduled { get; set; } 
} 

interface ITransactionalEntity 
{ 
    int ID { get; set; } 
} 

//sample class implementation 
class Teacher : ITeacher, ITransactionalEntity 
{ 
    private int _ID; 
    public int ID 
    { 
     get { return _ID; } 
     set { _ID = value; } 
    } 
    //implement interfaces 
    public void Save(SqlTransaction tran) 
    { 
     if (this.ID > 0) 
      //insert 
     else 
      //update 
    } 
} 

class ClassSession : IClassSession, ITransactionalEntity 
{ 
    //implement interfaces 
    public void Save(SqlTransaction tran) 
    { 
     this.Course.Save(tran); 
     this.Teacher.Save(tran); 
     if (this.ID > 0) 
      //insert 
     else 
      //update 
    } 
} 

... 
List<IClassSession> list = new List<IClassSession>(); 
ClassSession cs = new ClassSession(); 
cs.Course = new Course(courseID); 
cs.Teacher = new Teacher(teacherID); 
classlist.Add(cs); 
SqlTransaction tran; 
... 
foreach(IClassSession classsession in list) 
    classsession.Save(tran); 
... 

，你可以做任何你想要的，它的Linq等發揮你的想象力。並非所有東西都寫在這裏，就像一個想法。

Answer 4

如果你已經習慣了親子關係，那麼我建議你嘗試將它們建模爲兩個獨立的父子關係。例如，有一個屏幕可以編輯教師並允許他們添加現有課程。另一方面，你可以有一個課程屏幕，允許他們添加現有的treachers。遵循這個建議應該讓你的工作更輕鬆。從一個類的設計中，你可以用同樣的方式對它進行建模。課程課程將有一種方法將教師添加到教師的內部列表中。教師課程還可以將課程添加到內部課程列表中。這些類的物理結構實際上取決於你計劃如何保持對象。基於文件的持久性，xml序列化和數據庫持久性可以具有不同的內部對象結構。如果您是從實體級別或業務層級進行建模，那麼也存在階級差異。無論如何，希望我已經給你足夠的想法來運行它。