Was ist der Hauptvorteil von reinen POCO-Modellen? Ich verstehe, dass Modelle sauber und einfach sein sollten, aber ich neige dazu, die Pflege von untergeordneten Objekten in den Modellklassen beizubehalten. Zum Beispiel, wenn ich a ClassAund ClassBwie folgt definiert habe:
public class ClassA
{
public string MyProp { get; set; }
public IEnumerable<ClassB> Children { get; }
public void AddChild(ClassB newChild) { /*... */ }
public void RemoveChild(ClassB child) { /* ... */ }
}
public class ClassB
{
public string SomeProp { get; set; }
} Stimmt etwas mit den Methoden add und remove nicht? Sollte ich stattdessen einfach die Liste verfügbar machen und dem Client-Code erlauben, das hinzuzufügen, was auch immer die Verantwortung für einfache Datenüberprüfungen trägt, z. B. nicht null, und nicht an eine andere Klasse weiterzugeben?
Jede Hilfe wird geschätzt. Danke.
Wenn Sie jemals mit den Kopfschmerzen von ActiveRecord-Klassen mit Hunderten von Methoden umgegangen sind, die möglicherweise zu einem bestimmten Zeitpunkt nicht Ihren Wünschen entsprechen, ist es meiner Meinung nach einfacher, den Reiz zu verstehen.
—
Casey
Der Hauptgrund, dieses spezielle Design zu vermeiden, liegt darin, dass es den .net-Designrichtlinien widerspricht. Es ist völlig willkürlich, aber die Leute erwarten, dass die Sammlung die Mutationsmethoden enthält.
—
Frank Hileman
@Casey Ich verwende das Active Record-Muster nicht. Die Add-Methode führt lediglich eine geringfügige Datenüberprüfung durch. Die Methode remove ist vorhanden, da die Auflistung nicht verfügbar gemacht wird. Sie wird einfach einer internen Liste hinzugefügt und daraus entfernt. Ich habe es jedoch geändert, um einen anderen Auflistungstyp zu verwenden, mit dem ich die Validierung durchführen kann, während ich weiterhin die integrierten Methoden zum Hinzufügen / Entfernen verwende.
—
Jesse
AddChild(ClassB newChild) => Children.Add(newChild ?? new NullClassB())