DTO 与 WCF 层中的业务对象答案

【问题标题】：DTO vs Business objects in WCF layerDTO 与 WCF 层中的业务对象
【发布时间】：2013-04-15 09:35:10
【问题描述】：

我们的应用程序中有两个项目：

Web UI 项目（aspx 页面）。
WCF 项目。

这两个部分将进一步调用相同的 BL 和 DAL 层。这是架构：

网络项目：

WCF 项目（将使用 REST）：

上述业务对象和 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 使用的业务对象。此外，在我们的 WCF REST 层中，我们仅将 DTO 用于输入婴儿车：

  public MyResponse CreateUser(User user)
        {

通过这个方法，我们通过一些映射器将 DTO 转换为业务对象（即 UserDTO 到 User.cs 对象），并将其传递给仅接受业务对象而不接受 DTO 的 BL 层。即，从 WCF 将业务对象传递给 BL 和 DAL 的点来看，它的行为方式与 UI 将业务对象传递给 BL 和 DAL 层的方式完全相同。

使用 2 个单独的数据传输对象有什么实际优势？我问了这个问题，因为 IMO 这将是多余的，我们应该使用一个数据传输对象，即 Web 项目和 WCF 项目的业务对象。

【问题讨论】：

标签： c# asp.net wcf rest

【解决方案1】：

对我来说，是的，这样做总是值得的，但仅如果您将对象用于 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来注入发送的值从客户端到服务器上的完整对象。

【讨论】：