domain-driven-design - 什么时候适合将 DTO 映射回其对应的实体

Question

根据我阅读和实现的内容，DTO 是保存数据模型中值子集的对象，在大多数情况下，这些是不可变对象(immutable对象)。

我需要将新值或更改传回数据库的情况如何？

我应该在我的表示层中直接使用我的 DAL 中的数据模型/实际实体吗？

或者我应该创建一个可以从表示层传递到业​​务层的 DTO，然后将其转换为实体，然后通过 ORM 调用在数据库中更新。这是写太多代码吗？我假设如果表示层没有数据模型的概念，则需要这样做。如果我们采用这种方法，我是否应该在提交更改之前再次在 BLL 层获取对象？

Answer 1

Should I work directly with the data model/actual entity from my DAL in my Presentation layer?

这对于中小型项目来说是可以的。但是当你有一个超过 5 名开发人员的大型项目，其中不同的层被分配给不同的团队时，那么项目会受益于使用 DTO 将数据层与表示层分开。

中间有一个 DTO，表示层中的任何更改都不会影响数据层(反之亦然)

Or should I create a DTO that can be passed from the presentation layer to the business layer then convert it to an entity, then be updated in the DB via an ORM call. Is this writing too much code? I'm assuming that this is needed if the presentation layer has no concept of the data model. If we are going with this approach, should I fetch the object again at the BLL layer before committing the change?

对于创建新实体，这是通常的方法(例如“新用户”)。对于更新现有实体，您不会将 DTO 转换为实体，而是获取现有实体，映射新值然后启动 ORM 更新。

UpdateUser(UserDto userDto)
{
    // Fetch
    User user = userRepository.GetById(userDto.ID);

    // Map
    user.FirstName = userDTO.FirstName;
    user.LastName = userDTO.LastName;

    // ORM Update
    userRepository.Update(user);
    userRepository.Commit();
}

对于有许多开发人员的大型项目，与它提供的解耦的巨大优势相比，编写过多代码的劣势是微乎其微的。

见我关于 Why use a DTO 的帖子