DTO与Entity互转应放Controller还是Service层？转换方式哪种合理？

一、转换逻辑该放哪？DTO转Entity vs Entity接收DTO #

1. 你当前的实现（DTO里写of()方法） #

这种方式最核心的好处是契合依赖倒置原则：

• Entity是领域层的核心，只需要管好数据库映射和业务逻辑就行，完全不用依赖外部的DTO，避免了核心层和交互层的耦合。
• DTO本来就是用来承接外部请求的，它依赖Entity是合理的——毕竟表现层依赖核心业务层是常规分层设计的规矩。
• 唯一的小问题是如果以后有好几个DTO要转成同一个Entity，可能会有重复代码，但这个可以用专门的转换器类解决。

2. 别人建议的实现（Entity里写of(DTO)方法） #

这种方式其实有明显的设计问题：

• 违反单一职责原则：Entity的本职工作是封装业务状态和行为，没必要关心外部请求DTO的结构，这么写会让Entity变得臃肿，还会和表现层的变化绑定在一起。
• 搞反了依赖关系：核心的领域层（Entity）依赖了表现层（DTO），以后要是DTO改了结构，Entity也得跟着改，维护起来麻烦得很。

二、转换操作该放Controller还是Service？ #

1. 绝对别放Controller层 #

Controller的职责很明确：接请求、校验参数、返回响应，不该碰业务相关的转换逻辑：

• 转换过程里可能藏着业务规则（比如你代码里把oauthPlatform字符串转成枚举的逻辑），这属于业务范畴，放Controller会把职责搞混。
• 以后要是转换逻辑要调整（比如加个字段映射、改枚举转换规则），Controller代码会变得乱糟糟的，不好维护。

2. 推荐的几种实现方式 #

方式一：保留当前Service调用DTO的of()方法

你现在的Service代码是合理的，转换逻辑交给DTO，Service专心处理业务流程（比如保存用户）。要是以后需要扩展，直接在DTO里完善转换逻辑就行。

方式二：用独立的转换器类（更推荐）

专门建一个MemberConverter类，把DTO和Entity的互转逻辑都放在这里，彻底把DTO和Entity解耦：

public class MemberConverter {
    public static Member toEntity(MemberRegistRequestDto dto) {
        return Member.builder()
                .oauthId(dto.oauthId())
                .oauthPlatform(getOAuthProviderFromString(dto.oauthPlatform()))
                .name(dto.name())
                .profileImg(dto.profileImg())
                .nickname(dto.nickname())
                .birth(dto.birth())
                .gender(dto.gender())
                .profession(dto.profession())
                .signatureColor(dto.signatureColor())
                .build();
    }
}

然后Service层这么调用：

@Transactional
public void registMember(MemberRegistRequestDto memberRegistRequestDto) {
    Member member = MemberConverter.toEntity(memberRegistRequestDto);
    memberRepository.save(member);
}

这种方式的好处：

• 转换逻辑集中管理，不会出现重复代码。
• DTO和Entity各干各的，互不影响。
• 以后改转换逻辑，不用动DTO或Entity的核心代码，维护起来特别方便。

总结 #

• 转换逻辑优先放在DTO或者独立转换器类，坚决别让Entity依赖DTO。
• 转换操作一定要放在Service层或者转换器类，绝对不能放Controller层。
• 从长远来看，用独立转换器类（或者借助MapStruct这类工具）是最灵活、最好维护的方案。

内容的提问来源于stack exchange，提问作者Kevin