Построение графа объекта из плоского DTO с использованием шаблона посетителя

Я думаю, вы здесь действительно слишком усложняете. Просто используйте фабричный метод и позвольте вашим объектам домена четко указывать, от каких других объектов домена они зависят.

class Customer
{
    private readonly Name name;
    private readonly PostalAddress homeAddress;

    public Customer(Name name, PostalAddress homeAddress, ...)
    {
        this.name = name;
        this.homeAddress = homeAddress;
        ...
    }
}

class CustomerFactory
{
    Customer Create(CustomerDTO customerDTO)
    {
        return new Customer(new Name(...), new PostalAdress(...));
    }
}

Если вам нужно получить зависимость от Customer к CustomerDTO, передайте DTO в качестве дополнительного аргумента конструктору, возможно, заключенного в дополнительную абстракцию.

Таким образом, все будет оставаться чистым, доступным для тестирования и легким для понимания.

Не думаю, что пойду с посетителем. Это было бы уместно, если вы не знаете во время разработки, какие операции вам нужно выполнить над ним позже, поэтому вы открываете класс, чтобы другие могли писать посетителей, реализующих эту логику. Или есть так много вещей, которые вам нужно сделать на нем, что вы не хотите загромождать этим свой класс.

Здесь вы хотите создать экземпляр класса из DTO. Поскольку структура класса и DTO тесно связаны (вы выполняете сопоставление в базе данных, я предполагаю, что вы решаете все проблемы сопоставления на этой стороне и имеете формат DTO, который сопоставляется непосредственно со структурой вашего клиента), вы знаете на время разработки то, что вам нужно. Нет необходимости в большой гибкости. (Однако вы хотите быть надежным, чтобы код мог обрабатывать изменения в DTO, например, новые поля, без исключения исключений)

По сути, вы хотите создать клиента из фрагмента DTO. Какой у вас формат, просто XML или что-то еще?

Думаю, я бы просто выбрал конструктор, который принимает DTO и возвращает клиента (пример для XML :)

class Customer {
        public Customer(XmlNode sourceNode) {
            // logic goes here
        }
    }

Класс Customer может «обернуть» экземпляр DTO и «стать одним». Это позволяет очень естественно проецировать экземпляр вашего DTO в экземпляр клиента:

var c = new Customer(xCustomerNode)

Это обрабатывает выбор шаблона высокого уровня. Вы с этим согласны? Вот удар по конкретной проблеме, о которой вы упомянули, с попыткой передать свойства 'по ссылке'. Я действительно вижу, как DRY и KISS могут противоречить, но я бы постарался не задумываться над этим. Это может исправить довольно простое решение.

Так что для PostalAddress у него тоже будет собственный конструктор, как и у самого Customer:

public PostalAddress(XmlNode sourceNode){
   // here it reads the content into a PostalAddress
}

по заказчику:

var adr = new PostalAddress(xAddressNode);

Проблема, которую я вижу здесь, заключается в том, где вы помещаете код, который определяет, если это InvoiceAddress или HomeAddress? Это не относится к конструктору PostalAddress, потому что в дальнейшем для PostalAddress могут быть другие применения, вы не хотите жестко кодировать его в классе PostalAddress.

Так что эту задачу нужно решать в классе Customer. Здесь определяется использование почтового адреса. Он должен быть в состоянии определить по возвращаемому адресу, какой это адрес. Я предполагаю, что самым простым подходом было бы просто добавить свойство на PostalAddress, которое сообщает нам:

public class PostalAddress{
  public string AdressUsage{get;set;} // this gets set in the constructor

}

а в DTO просто укажите это:

<PostalAddress usage="HomeAddress" city="Amsterdam" street="Dam"/>

Затем вы можете посмотреть его в классе Customer и «прикрепить» к нужному свойству:

var adr = new PostalAddress(xAddressNode);
switch(adr.AddressUsage){
 case "HomeAddress": this.HomeAddress = adr; break;
 case "PostalAddress": this.PostalAddress = adr; break;
 default: throw new Exception("Unknown address usage");
}

Думаю, простого атрибута, который сообщает Заказчику, какой это тип адреса, будет достаточно.

Как это звучит до сих пор? Код ниже объединяет все это воедино.

class Customer {

        public Customer(XmlNode sourceNode) {

            // loop over attributes to get the simple stuff out
            foreach (XmlAttribute att in sourceNode.Attributes) {
                // assign simpel stuff
            }

            // loop over child nodes and extract info
            foreach (XmlNode childNode in sourceNode.ChildNodes) {
                switch (childNode.Name) {
                    case "PostalAddress": // here we find an address, so handle that
                        var adr = new PostalAddress(childNode);
                        switch (adr.AddressUsage) { // now find out what address we just got and assign appropriately
                            case "HomeAddress": this.HomeAddress = adr; break;
                            case "InvoiceAddress": this.InvoiceAddress = adr; break;
                            default: throw new Exception("Unknown address usage");
                        }    
                        break;
                    // other stuff like phone numbers can be handeled the same way
                    default: break;
                }
            }
        }

        PostalAddress HomeAddress { get; private set; }
        PostalAddress InvoiceAddress { get; private set; }
        Name Name { get; private set; }
    }

    class PostalAddress {
        public PostalAddress(XmlNode sourceNode) {
            foreach (XmlAttribute att in sourceNode.Attributes) {
                switch (att.Name) {
                   case "AddressUsage": this.AddressUsage = att.Value; break;
                   // other properties go here...
            }
        }
    }
        public string AddressUsage { get; set; }

    }

    class Name {
        public string First { get; set; }
        public string Middle { get; set; }
        public string Last { get; set; }
    }

и фрагмент XML. Вы ничего не сказали о своем формате DTO, подойдет и для других форматов.

<Customer>  
  <PostalAddress addressUsage="HomeAddress" city="Heresville" street="Janestreet" number="5"/>
  <PostalAddress addressUsage="InvoiceAddress" city="Theresville" street="Hankstreet" number="10"/>
</Customer>

С уважением,

Герт-Ян

Для преобразования между классом модели и DTO я предпочитаю делать одно из четырех:

а. используйте оператор неявного преобразования (особенно при переходах из json в dotnet).

public class Car
{
    public Color Color {get; set;}
    public int NumberOfDoors {get; set;}        
}

public class CarJson
{
    public string color {get; set;}
    public string numberOfDoors { get; set; }

    public static implicit operator Car(CarJson json)
    {
        return new Car
            {
                Color = (Color) Enum.Parse(typeof(Color), json.color),
                NumberOfDoors = Convert.ToInt32(json.numberOfDoors)
            };
    }
}

а затем использование

    Car car = Json.Decode<CarJson>(inputString)

или проще

    var carJson = new CarJson {color = "red", numberOfDoors = "2"};
    Car car = carJson;

вуаля, мгновенное преобразование :)

http://msdn.microsoft.com/en-us/library/z5z9kes2.aspx

б. Используйте проекцию linq, чтобы изменить форму данных

IQueryable<Car> cars = CarRepository.GetCars();
cars.Select( car => 
    new 
    { 
        numberOfDoors = car.NumberOfDoors.ToString(), 
        color = car.Color.ToString() 
    } );

c. Используйте комбинацию из двух

d. Определите метод расширения (который также можно использовать в проекции linq)

public static class ConversionExtensions
{
    public static CarJson ToCarJson(this Car car)
    {
        return new CarJson {...};
    }
}

CarRepository.GetCars().Select(car => car.ToCarJson());

Вы можете воспользоваться подходом, который я описал здесь: преобразовать набор результатов плоской базы данных в коллекцию иерархических объектов на C #

Идея состоит в том, чтобы прочитать объект, например Customer, и поместить его в словарь. При чтении данных, например, CustomerAccount, теперь вы можете взять клиента из Словаря и добавить учетную запись клиента к клиенту.

У вас будет только одна итерация по всем данным для построения графа объектов.