Erstellen eines Objekts - statische Builder-Methode vs. Builder-Klasse vs. Erweiterungsmethode

Question

Ich bin gespannt, ob jemand Vorschläge oder alternative Muster zum Erstellen eines benutzerdefinierten Objekts mit Daten von einem anderen Objekt hat.

Wir untersuchen derzeit drei Ansätze.

1) statische Aufladung Method

public class MyObject 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public static MyObject Build(DataRow data) 
    { 
     MyObject newObject = new MyObject(); 
     newObject.Id = Convert.ToInt32(data["ID"]); 
     newObject.Name = Convert.ToString(data["NAME"]); 
     return newOjbect; 
    } 
} 

2) Builder Klasse

public class MyObject 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
} 

public class MyObjectBuilder 
{ 
    public static MyObject Build(DataRow data) 
    { 
     MyObject newObject = new MyObject(); 
     newObject.Id = Convert.ToInt32(data["ID"]); 
     newObject.Name = Convert.ToString(data["NAME"]); 
     return newOjbect; 
    } 
} 

3) Erweiterungsmethode

public class MyObject 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
} 

public static class MyObjectExtensions 
{ 
    public static void Build(this MyObject obj, DataRow data) 
    { 
     obj.Id = Convert.ToInt32(data["ID"]); 
     obj.Name = Convert.ToString(data["NAME"]); 
    } 
} 

Ein Hauptüberlegungspunkt ist, dass wir bei jedem Ansatz, den wir verfolgen, eine using Referenz von System.Data hinzufügen müssen. An dieser Stelle zögern wir, diese Abhängigkeit direkt zu unserer Klasse MyObject hinzuzufügen.

Kann irgendjemand irgendeinen dieser Vor- oder Nachteile anbieten oder Alternativen anbieten, die Erweiterbarkeit und Testbarkeit besser ermöglichen?

Answer 1

Nachteil des ersten Ansatzes ist, dass Sie die Objektdefinition mit der Builder-Logik verwechseln. Wenn Sie sich für die Gesamtarchitektur entscheiden, für die Sie sich entscheiden, sollten Sie Ihre Modellobjekte lieber als POCOs betrachten, sodass die Kopierlogik nicht definiert ist.

Ich würde auch nicht die Erweiterungsmethode verwenden, da sie meiner Meinung nach relevanter für das Erweitern von Features aus dem Framework sind (normalerweise die String- oder IEnumerable-Klassen), wenn Sie ein bestimmtes Feature in Ihrem gesamten Projekt benötigen.

Also die zweite Lösung ist interessant, da es Ihnen ermöglicht, die Objektdefinition von der Baulogik zu trennen. Sie können jedoch die Anzahl der Objekte berücksichtigen, auf die diese Anwendung angewendet werden soll. Wenn Sie viele von ihnen haben, könnte es ein Chaos werden, um zu erhalten.

Answer 2

können Sie Konstrukteure verwenden

public class MyObject 
{ 
    public int Id { get; private set; } 
    public string Name { get; private set; } 

    public MyObject(int Id,string Name) 
    { 
     this.Id = Id; 
     this.Name = Name; 
    } 

    public MyObject(DataRow data) 
    { 
     Id = Convert.ToInt32(data["ID"]); 
     Name = Convert.ToString(data["NAME"]); 
    } 
} 

Wenn Id Typ Guid wurde dort Standardkonstruktors sein kann.

MyObject myObject = new MyObject(data) 

sieht besser lesbar dann

MyObject myObject = MyObject.Build(data) 

denke ich Erweiterungsmethode paßt nicht, weil die Schaffung von Objekt Zustand verwendet, aber nicht auf dem Verhalten, während Erweiterungsmethoden Verhalten des Objekts verwendet.