Aktualisieren von verwandten Entitäten DDD

Question

Ich bin verwirrt, wie ich zu verwandten Entitäten mit DDD aktualisiert werde. Sagen wir, ich habe eine Mitarbeiterklasse und eine Arbeitsschaltklasse. Wie sollte ich einen bestimmten Arbeitsablauf eines bestimmten Mitarbeiters aktualisieren? Die Beziehung zwischen Employee und Workt Schedule ist One-to-Many. Unten ist der Code, den ich benutze, um einen bestimmten Arbeitsplan hinzuzufügen/zu aktualisieren.

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; } 
} 

Ist das korrekt? Habe ich DDD richtig verstanden? Auch mein Denken ist gerade jetzt Workschedule ein Wertobjekt, aber ich stelle und ID für die Normierung

Answer 1

Ihr Modell sollte „POCO“ Klasse

CRUD Methoden wie sein .. oder bearbeiten hinzufügen wird Considored im Rahmen von „Service“ oder „Repository“

hier ist eine kurze Idee, die mir in den Sinn kam gerade/wie es sein und seine Verwendung aussehen sollte ..

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); 

Answer 2

Da hier alles EF bezogen ist, ist es nicht viel von DDD. Wenn der Code wie gewünscht funktioniert, ist es in Ordnung. Aber DDD hat keine Beziehung zu EF oder irgendeinem anderen ORM. Sie sollten die Domänenobjekte entwerfen, ohne sich um die Datenbank oder ein ORM zu kümmern. Dann ordnen Sie im Repository die Domain-Entitäten den Persistenz-Entitäten zu, die vom ORM verarbeitet werden.

Auch mein Denken ist gerade jetzt Workschedule ein Wertobjekt, aber ich stelle und ID für die Normierung

Dies ist die Folge, wenn die Schichten und Modelle gemischt werden. Sie benötigen keine ID in der Domäne, aber Sie benötigen eine ID für die Persistenz. Der Versuch, beide Anforderungen in ein Modell zu integrieren und diese Modelldomäne aufzurufen, führt zu nichts.

Answer 3

EF es ist nicht für DDD, es ist zu ungeschickt. EF ist für die gleichen Codemonkeys, die SQL-Tabellen zu Entities zuordnen und es wie ActiveRecord-Antipatter machen, aber nachdem intelligentere Entwickler dies als eine schlechte Praxis zu bezeichnen begannen, begannen sie, ORM, Entities zu verwenden und Monkey-Coding fortzusetzen.

Ich kämpfe mit EF letzte 3 Jahre, um es DDD Weg arbeiten zu lassen. Es widersteht erfolgreich und gewinnt. Ohne Hacks funktioniert es nicht. Die auf-zu-viele-Beziehungen funktionieren immer noch nicht wie erwartet, es gibt keine Möglichkeit, Entitäten mit Konstruktor zu erstellen, nicht die öffentlichen Eigenschaften und so weiter.