DTO到域模型的转换策略

Question

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

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

我在API中的一个控制器是Employee控制器，您可以对它执行所有CRUD操作。我已经创建了一个EmployeeDo对象来与控制器一起使用——例如，它可能看起来像这样：

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（例如，NewEmployeeDo、ExistingEmployeeTo）。

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

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

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

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

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

Answer 1

对于您所描述的情况，共享相同的DTO并忽略一些没有意义的属性是可以的。

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

Answer 2

在我看来，DTO不应该像Value Object那样具有标识。我所做的是，如果创建和更新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);