2

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

  1. Web UI 项目（aspx 页面）。
  2. 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 项目的业务对象。

4

1 回答 1

3

对我来说，是的，这样做总是值得的，但前提是您将对象用于 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-15T09:53:30.720 回答