放下還是不放？從數據庫建模類tables.-

傢伙，我有另一個「最佳實踐問題」放下還是不放？從數據庫建模類tables.-

例如，我有我的SQL Server上此表：

-------------- 
Table: Client 
-------------- 
(PK) clientID  long, 
    clientName varchar(50) 


--------------- 
Table: Training 
--------------- 
(PK) trainingID long, 
(FK) clientID  long, 
     trainingName varchar(50)

現在即時通訊使用LINQ2SQL這些表映射.-但是如果現在我想創建一個業務層什麼Im做是創建普通的對象建模那些tables.-例如：

public class Client 
{ 
    public long clientID {get; set; 
    public string clientName {get; set;} 
} 

public class Training 
{ 
    public long trainingID {get; set;} 
    // And here goes my question!! 
    public long clientID {get; set;} // <--- Should this be here 
    public string trainingNane {get; set;} 
}

或者我應該刪除那裏修改我的客戶端類的：

public class Client 
{ 
    public long clientID {get; set; 
    public string clientName {get; set;} 
    public List<Training> myTrainings {get; set;} //Clients have Trainings! 
}

我的意思是我應該創建類的DB是或者我應該使用常識和人物，一個客戶有很多培訓（我會再創建一個方法找到他的課程）一方法是這樣的（可能是在ClientHelper類）：

public List<Training> findMyTranings(long clientID) 
{ 
    // Find the Trainings for that particular client 
}

我希望你明白這個愚蠢的問題，是關於如何提前classes.-

感謝典範！！

來源

2010-02-15 MRFerocius

您希望後者 - 對象之間的顯式關係，以便您的業務邏輯可以根據對象（myClient.Trainings）而不是數據庫模式（具有clientid = x的一組訓練集）工作。這是對象關係映射的基礎，不管你是否使用特殊的工具來處理它（我推薦使用ORM工具）。使您的訪問代碼更加智能，這樣您的業務邏輯就不必如此。

來源

2010-02-15 23:07:20

這是我怎麼會想到它是：

public class Client 
{ 
    public long ClientID {get; set; 
    public string ClientName {get; set;} 
    public IList<Training> Trainings {get; set;} 
} 

public class Training 
{ 
    public long TrainingID {get; set;} 
    public Client Client {get; set;} 
    public string TrainingNane {get; set;} 
}

這是你提出什麼樣的一個超集的東西，再加上暴露客戶作爲培訓的對象，而不是作爲一個長期的客戶端ID的。

看來我的提議與LinqToSql生成的內容完全匹配（但清晰的POCO對象），但我可能沒有正確記住。

來源

2010-02-16 09:06:06

放下還是不放？從數據庫建模類tables.-

回答

相關問題