更新相關實體DDD

我很困惑我將如何使用DDD更新相關實體。假設我有一個Employee Class和Workschedule Class。我應該如何更新某個員工的特定工作計劃？ Employee和Workschedule之間的關係是一對多關係。以下是我正在使用的代碼如何添加/更新某個作品計劃。更新相關實體DDD

public class Employee 
{  
    public int EmployeeId { get; set; } 
    public virtual ICollection<WorkSchedule> WorkSchedules { get; set; } 

    public WorkSchedule AddWorkSchedule(WorkSchedule workSchedule) 
    { 
     this.WorkSchedules.Add(workSchedule); 

     return workSchedule; 
    } 

    public WorkSchedule EditWorkSchedule(WorkSchedule workSchedule) 
    { 
     var originalWorkSchedule = this.WorkSchedules.FirstOrDefault(w => w.WorkscheduleId == workSchedule.WorkscheduleId); 

     originalWorkSchedule.ClockIn = workSchedule.ClockIn; 
     originalWorkSchedule.ClockOut = workSchedule.ClockOut; 

     return originalWorkSchedule; 
    } 
} 
public class WorkSchedule 
{ 
    public int WorkScheduleId { get; set; } 
    public DateTime ClockIn { get; set; } 
    public DateTime ClockOut { get; set; } 

    public int EmployeeId { get; set; } 
}

這是正確的嗎？我是否正確遵循DDD？另外，我的思想現在Workschedule是一個值對象，但我把與ID爲正常化的目的

來源

2012-04-07 gnaungayan

你的模式應該是「POCO」類

CRUD方法等.. 添加或編輯會被considored爲「服務」或「資源庫」

這裏是剛剛來到我的腦海/應該如何看起來像及其使用快速想法的一部分。這

IRepository repository { get; set; } //implement Interface and inject via IoC Container 

//..usage 
var employee = repository.GetEmployee(123); //get by id 
//..new WorkSchedule 
employee.WorkSchedules.Add(workSchedule); 

var result = repository.Save(employee);

來源

2012-04-07 07:11:41 aifarfa

我也在想這種方法，但我很困惑，因爲workschedule不能存在沒有任何員工多數民衆贊成爲什麼我在Employee類上創建一個添加方法。 Add方法只在列表上添加工作日程表，不在DB – gnaungayan 2012-04-07 07:16:43

它的模型驗證（WorkSchedule.EmployeeId不能爲NULL）。你可以在模型上使用'System.ComponentModel.DataAnnotations'或實現'IValidatableObject'。這樣'Save（）'方法可以在保存之前驗證模型。請參閱[實體框架4.1驗證]（http://msdn.microsoft.com/en-us/data/gg193959） – aifarfa 2012-04-07 07:29:02

所以你說的與Orders和OrderLines相同的情況 – gnaungayan 2012-04-07 10:22:06

因爲這裏的一切都是EF相關的，所以它不是很大的DDD。如果代碼正常工作，那就沒問題。但DDD與EF或任何其他ORM沒有任何關係。您應該設計Domain對象，而不關心數據庫或ORM。然後，在存儲庫中將Domain實體映射到將由ORM處理的Persistence實體。

而且，我的思想現在Workschedule是一個值對象，但我把與ID爲正常化的目的

這是結果，當層和模型混合。你不需要域中的ID，但你需要一個id來進行持久化。試圖在一個模型中適應這兩個要求並調用該模型域導致無處。

來源

2012-04-07 07:35:43 MikeSW

實際上，我不涉及任何ORM在這裏，我的DAL非常具有可擴展性，可以隨時實現NH，EF等。謝謝 – gnaungayan 2012-04-07 10:23:40

你在這裏顯示的代碼顯然是爲ORM量身定做的，否則我不明白爲什麼WorkSchedules是虛擬的，並且有一個公共setter。順便說一下，DDD沒有硬性規定。規則是由DOMAIN自己定義的，因此如果代碼模擬您想要解決的現實生活問題，您應該最清楚。另外，如果WorkSchedule是一個值對象，它應該是不變的，所以沒有公開制定者。 – MikeSW 2012-04-07 10:31:15

謝謝邁克我想我在這裏看到「燈泡」 – gnaungayan 2012-04-07 11:58:42

EF它不適用於DDD，它太笨拙了。 EF適用於喜歡將SQL表映射到實體並像ActiveRecord反patter一樣執行的相同代碼鍵，但在更聰明的開發人員開始稱這是一種不好的做法後，他們開始使用ORM，實體並繼續進行猴編碼。

我在EF最近3年努力讓它工作DDD的方式。它成功抵制並獲勝。沒有黑客它不工作。一對多關係仍然無法按預期工作，沒有辦法用構造函數創建實體，而不是公共屬性等。

來源

2015-04-21 18:31:21

更新相關實體DDD

回答

相關問題