Hình dạng DTO: phẳng, phức tạp/lồng nhau hoặc hỗn hợp cả hai

Question

Tôi có ứng dụng n-tier MVC2 (DAL, Tên miền, Dịch vụ, web MVC) bằng cách sử dụng phương pháp DDD (Thiết kế Driven miền), có Mô hình miền với kho lưu trữ. Tầng dịch vụ của tôi sử dụng mẫu Yêu cầu/phản hồi, trong đó các đối tượng Yêu cầu và phản hồi chứa DTO (đối tượng truyền dữ liệu) để sắp xếp dữ liệu từ lớp này sang lớp khác và ánh xạ được thực hiện thông qua trợ giúp từ AutoMapper. Câu hỏi của tôi là: DTO thường sử dụng hình dạng nào? Có thể có lồng nhau/phức tạp DTO hay không hoặc nó có phải là một dự án phẳng không? Hoặc có thể là hỗn hợp của cả hai? Ngoài ra, lý do chính để có DTO bằng phẳng so với DTO phức tạp/lồng nhau là gì?

Ví dụ, giả sử tôi đã có một miền như sau:

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; } 
} 

Có ba cách khác nhau tôi đã nghĩ đến việc mô hình hóa các đối tượng Response.

Lựa chọn 1 - tùy chọn DRYest:

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

Từ nghiên cứu tôi đã thực hiện, nó sẽ là không thích hợp cho một DTO để có một hình dạng tương tự như các đối tượng miền (s) như trình bày ở trên .

Lựa chọn 2 - một chiếu phẳng của miền (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; } 
} 

Đây là đơn giản hơn, giống như một DTO rõ ràng nên được, nhưng cuối cùng làm cho hơn DTOs.

Lựa chọn 3 - một hỗn hợp của cả hai:

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

Điều này cho phép mã được một chút khô hơn, tái sử dụng và dễ quản lý, và không tiếp xúc với cấu trúc tên miền của tôi cho người dùng cuối . Lợi ích chính khác là các phản hồi khác, như GetCompanyResponse chỉ đơn giản là có thể trả về CompanyDTO mà không phải sao chép tất cả các thuộc tính đó, tương tự như tùy chọn 2. Bạn nghĩ sao? Lựa chọn nào trong số này (nếu có) bạn đã thực hiện và/hoặc đã làm việc cho bạn? Nếu những yêu cầu/phản hồi sau này được tiếp xúc như các phương pháp dịch vụ WCF, câu trả lời của bạn có thay đổi không?

Answer 1

Sở thích cá nhân của tôi sẽ cố gắng và giữ cho nó phẳng nhất có thể với chỉ dữ liệu bắt buộc được chuyển. có nói rằng tôi đã sử dụng DTO lồng nhau sâu trong quá khứ bởi vì nó có ý nghĩa vào thời điểm đó và trang bị các yêu cầu. vì vậy tôi đoán nó đi xuống để "nó phụ thuộc". Vào cuối ngày đi với những gì có ý nghĩa cho các ứng dụng trong tầm tay. Không có điểm cố gắng để giày sừng dữ liệu vào một hội nghị DTO mà không phù hợp với những gì bạn đang buộc phải đạt được.