DTO 到域模型的转换策略答案

【问题标题】：DTO to domain model conversion strategiesDTO 到域模型的转换策略
【发布时间】：2013-12-03 10:20:48
【问题描述】：

我目前正在.NET Web API 中开发一个 RESTful API，并且有一个域模型（使用实体框架）和一个 DTO 模型来发送给客户端。

显然，API 中的域模型和 DTO 模型之间存在一些映射。

我在 API 中的一个控制器是 Employee 控制器，您可以对它执行所有 CRUD 操作。我创建了一个与控制器一起使用的 EmployeeDto 对象 - 例如，它可能如下所示：

public class EmployeeDto
{
   public Guid Id { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
}

而我的控制器可能有以下动作方法：

public EmployeeDto Get(Guid employeeId)
{
...
}

我的两难选择是为控制器中的每个操作使用相同的 DTO 类是否合适，或者是否为每个操作创建不同的 DTO（例如，NewEmployeeDto、ExistingEmployeeDto）。

使用相同 DTO 的一个问题是 DTO 的某些成员可能不适合（或多余）某些操作。例如，上面的 EmployeeDto 实例可能会传递给下面的动作，但它的 Id 成员是没有意义的，因为只有在域对象被持久化到存储时才会生成 Id。只有在将 Dto 发送回客户端时才应使用 Id 成员。

public void CreateEmployee(EmployeeDto employee)
{
...
}

上面没有问题，因为我们根本没有将 DTO 的 Id 属性映射到我们的域对象，但是我想知道是否创建一个名为 NewEmployeeDto 的新 DTO 会更好，它只在 CreateEmployee 中使用方法，它看起来像这样：

public class NewEmployeeDto
{
public string FirstName { get; set; }
public string LastName { get; set; }
}

我看到的问题是，如果需求发生变化并且需要将其他数据添加到 DTO，那么您可能必须在三个不同的类中进行相同的更改：ReturnEmployeeDto、NewEmployeeDto、ExistingEmployeeDto。因此，在某些情况下，维护量会增加三倍。

【问题讨论】：

标签： .net asp.net-web-api dto

【解决方案1】：

对于您描述的情况，可以共享相同的 DTO，如果某些属性无意义，则忽略它们。

仅仅因为 NewEmployee 没有 Id 就将 NewEmployee 和 ExistingEmployee 拆分为两个单独的类是过分的。

【讨论】：

【解决方案2】：

在我看来，DTO 不应该像值对象那样具有标识。我所做的是，如果创建和更新 DTO 相同，则使用单个 DTO。我的命名约定是使用“编辑”后缀，例如EmployeeEdit.

API 是：

public EmployeeEdit New(); // new employee default values
public Guid Create(EmployeeEdit input);
public EmployeeEdit Edit(Guid id); // populate edit form
public void Update(Guid id, EmployeeEdit input);
public void Delete(Guid id);

【讨论】：