Budowanie obiektu - metoda statycznego konstruktora a klasa konstruktora a metoda rozszerzenia

Question

Jestem ciekawa, czy ktoś ma jakieś sugestie lub alternatywne wzorce do budowania niestandardowego obiektu z danymi z innego obiektu.

Obecnie badamy trzy podejścia.

1) Static Budowanie Metoda

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) Konstruktor klasy

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) metodę rozszerzenia

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"]); 
    } 
} 

Jedną z głównych kwestii jest to, do której zbliżamy się, że musimy dodać do klasy odniesienie using z System.Data. W tym momencie nie chcemy dodawać tej zależności bezpośrednio do naszej klasy MyObject.

Czy ktoś może zaoferować korzyści lub wady jakimkolwiek z tych podejść lub może zaoferować rozwiązania alternatywne, które w większym stopniu umożliwią rozszerzalność i testowalność?

Answer 1

Wadą pierwszego podejścia jest to, że miesza się definicję obiektu z logiką budowniczego. Biorąc pod uwagę ogólną architekturę, którą wybierzesz, możesz chcieć, aby obiekty modelu były obiektami POCO, a więc nie ma zdefiniowanej w nich logiki kopiowania.

Nie użyłbym również metody rozszerzenia, ponieważ są one, moim zdaniem, bardziej odpowiednie do rozszerzenia funkcji z frameworka (zazwyczaj ciąg lub klasy IEnumerable), gdy potrzebujesz określonej cechy przez cały twój projekt.

Drugie rozwiązanie jest interesujące, ponieważ pozwala oddzielić definicję obiektu od logiki budynku. Można jednak wziąć pod uwagę liczbę obiektów, które mają zostać zastosowane. Jeśli masz ich wiele, może to być bałagan do utrzymania.

Answer 2

Można użyć konstruktorów

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"]); 
    } 
} 

Jeśli Id typu zostało Guid może istnieć konstruktor domyślny.

MyObject myObject = new MyObject(data) 

wygląda bardziej czytelny następnie

MyObject myObject = MyObject.Build(data) 

myślę metodę rozszerzenia nie pasuje, ponieważ stworzenie obiektu związana z państwem, ale nie do zachowań, natomiast rozszerzenie metod związanych z zachowaniem obiektu.