DTO VS在WCF層的業務對象

我們在我們的應用程序的兩個項目：DTO VS在WCF層的業務對象

的Web UI項目（aspx頁面）。
WCF項目。

這兩個部分將進一步調用相同的BL和DAL層。下面是結構：

Web項目：

enter image description here

WCF項目（其將被使用REST）：

enter image description here

業務對象和DTO的實施例如上所述：

public class User 
{ 
    public int UserID { get; set; } 
    public string UserName { get; set; } 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
} 

public class UserDTO 
{ 
    public int UserID { get; set; } 
    public string UserName { get; set; } 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
}

是否值得爲WCF REST層設置單獨的數據傳輸對象UserDTO.cs？我們已經將User.cs作爲Web項目BL和DAL正在使用的Business對象。此外，在我們的WCF REST層，我們使用DTO只爲輸入嬰兒車：

public MyResponse CreateUser(User user) 
     {

，並從這種方法，我們通過一些映射轉換DTO到業務對象（即UserDTO到User.cs對象），並將其傳遞BL層只接受Business對象而不接受DTO。即從WCF將Business對象傳遞給BL和DAL的角度來看，它的行爲與UI將Business對象傳遞給BL和DAL層的方式完全相同。

使用2個單獨的數據傳輸對象有什麼實際優勢嗎？我問過這個問題，因爲IMO會是多餘的，我們應該使用一個數據傳輸對象，即Web項目和WCF項目的業務對象。

來源

2013-04-15 Rocky Singh

對我來說，是的，它總是值得這樣做，但是只有如果您使用對象進行AJAX調用。

在這種情況下它進入自己的：

public class User 
{ 
    public int UserID { get; set; } 
    public string UserName { get; set; } 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
} 

public class UserDTO 
{ 
    // Hide the UserID 
    public string UserName { get; set; } 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
}

你真的希望用戶能夠看到的Ajax響應並得到用戶ID？可能不會。這就是我們使用單獨的DTO的原因。它還確保您只使用輕量級對象，而不是完整的，可能很重的對象，以便在客戶端和服務器之間進行數據傳輸。

當然，你也可以這樣做：

var query = GetYourUsers(); 

return query.Select(a => new { a.UserName, a.FirstName, a.LastName });

哪個更輕便，那麼你可以使用User對象從客戶端發送數據到服務器端，並使用工具，例如Value Injector將發送的值從客戶端注入服務器上的完整對象。

來源

2013-04-15 09:53:30

DTO VS在WCF層的業務對象

回答

相關問題