在這種情況下使用DTO的正確方法是什麼？

Question

我有以下域類：

public class Product 
{ 
    public virtual Guid Id { get; set; } 
    public virtual string Name { get; set; } 
    public virtual IList<Product> RelatedProducts { get; set; } 
} 

我有以下DTO類：

public class ProductDTO 
{ 
    public ProductDTO(Product product) 
    { 
     Id = product.Id; 
     Name = product.Name; 
    } 

    public Guid Id { get; private set; } 
    public string Name { get; private set; } 
} 

我在我的服務提出了以下方法：

public ProductDTO GetBySlug(string slug) 
{ 
    Product product = productRepository.GetBySlug(slug); 
    return (product != null) ? new ProductDTO(product) : null; 
} 

我有以下在我的控制器中執行操作：

public ActionResult Details(string slug) 
{ 
    ProductDTO viewModel = productService.GetBySlug(slug); 
    return View("Details", viewModel); 
} 

在閱讀了一下之後，我的理解是，使用DTO作爲視圖模型是可以的，因爲當前的場景很簡單直接。當我想要返回的數據變得更加複雜時，我會發生混淆。假設我也想將相關產品列表返回到視圖。我會在哪裏添加這個列表？

我讀到DTO是用於傳輸數據的域實體的扁平版本。這是否意味着在DTO內部不應允許包含相關產品的通用清單？我迄今收到的答案表明如此。那我如何將相關產品交給控制器？

一種選擇是：

而是在服務返回ProductDTO的我會創建一個保存ProductDTO和類型ProductDTO對相關產品的列表中的新類，並從服務返回。在控制器中，我會將新類傳遞給視圖，或者創建一個單獨的ProductViewModel，其中包含ProductDTO和相關產品的ProductDTO列表，並填充它並將其傳遞給視圖。

這是個好主意還是壞主意？爲什麼？

感謝

Answer 1

我不會列表放在裏面DTO在所有的，因爲它不自然屬於那裏。而且我也不確定你的'包裝類'是什麼意思。所有你需要的是一個產品列表，在返回這個列表的服務上有另一個方法是完全可以的。

因此，你有這樣的事情在你的服務：

public IList<ProductDTO> GetRelatedProducts(ProductDTO productDTO) 
{ 
    ... 

一個視圖模型（被稱爲以上服務的東西）背後的最重要的觀點是，它的UI和之間起中介作用商業模式。換句話說：它以與UI相關的方式編排和彙總業務模型。如果用戶界面在某個時候想要一個相關產品的列表，那麼該服務必須提供它。它非常簡單，在這裏，商業模式本身是否也有這個概念是完全不相干的。

HTH！ Thomas

P.S. 如果您的DTO變大並且您的列表變長，那麼您可能會考慮引入另一個（簡化的）DTO，僅使用名稱和某種標識符來減少必須從存儲庫檢索的不必要數據量。