DTO Form: flach, komplex/verschachtelt oder eine Mischung aus beiden

Question

Ich habe eine MVC2 n-Tier-Anwendung (DAL, Domain, Service, MVC-Web) mit einem DDD-Ansatz (Domain Driven Design), mit einem Domain Model mit Repositories. Meine Serviceschicht verwendet ein Request/Response-Muster, in dem die Request- und Response-Objekte DTOs (Data Transfer Objects) enthalten, um Daten von einer Schicht zur nächsten zu übertragen. Die Zuordnung erfolgt über die Hilfe von AutoMapper. Meine Frage ist diese: welche Form sollte ein DTO normalerweise nehmen? Kann es haben verschachtelt/komplex DTO ist auch oder sollte es streng eine flach Projektion? Oder möglicherweise eine Mischung aus beidem? Was sind auch die Hauptgründe dafür, ein flaches DTO gegenüber einem komplexeren/verschachtelten DTO zu haben?

Zum Beispiel: Angenommen ich eine Domain wie die folgenden hatte:

public class Employee 
{ 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
    public Company Company { get; set; } 
} 
public class Company 
{ 
    public string Name { get; set; } 
    public string Address { get; set; } 
    public string City { get; set; } 
    public string State { get; set; } 
} 

Es gibt drei verschiedene Möglichkeiten, wie ich von der Modellierung des Response-Objekt gedacht haben.

Option 1 - die trockenste Option:

public class GetEmployeeResponse 
{ 
    public class EmployeeDTO { get; set; } // contains a CompanyDTO property 
} 

Von der Forschung, die ich getan habe, wäre es unangemessen, für eine DTO eine ähnliche Form wie das Domain-Objekt zu übernehmen (s), wie oben gezeigt, .

Option 2 - ein abgeflachte Vorsprung der Domäne (anti-DRY):

public class GetEmployeeResponse 
{ 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
    public string CompanyName { get; set; } 
    public string CompanyAddress { get; set; } 
    public string CompanyCity { get; set; } 
    public string CompanyState { get; set; } 
} 

Dies ist einfacher, wie ein DTO sollte offensichtlich sein, aber letztlich für mehr DTOs macht.

Option 3 - eine Mischung aus beidem: meine Domain nicht Struktur an den Endverbraucher

public class GetEmployeeResponse 
{ 
    public EmployeeDTO Employee { get; set; } 
    public CompanyDTO Company { get; set; } 
} 

Dies ermöglicht den Code ein wenig trocken, wiederverwendbar und überschaubar zu sein, und belichten . Der andere Hauptvorteil besteht darin, dass andere Antworten wie GetCompanyResponse einfach CompanyDTO zurückgeben können, ohne eine Kopie all dieser Eigenschaften erstellen zu müssen, ähnlich wie Option 2. Was denken Sie? Welche dieser Optionen haben Sie für sich genommen und/oder gearbeitet? Wenn diese Requests/Responses später als WCF-Service-Methoden verfügbar gemacht werden, ändert sich Ihre Antwort?

Answer 1

Meine persönliche Vorliebe wäre es zu versuchen, es so flach wie möglich zu halten und nur die erforderlichen Daten zu übertragen. Ich habe gesagt, dass ich in der Vergangenheit tief verschachtelte DTO verwendet habe, weil es damals sinnvoll war und die Anforderungen erfüllte. Ich denke, es kommt darauf an "es kommt darauf an". Am Ende des Tages gehen Sie mit, was für die vorliegende Anwendung sinnvoll ist. Kein Punkt, der versucht, Horndaten in eine DTO-Konvention zu schuhen, die nicht zu dem passt, was Sie erreichen wollen.