Controller层应返回Model还是DTO？初级开发者的技术困惑

我是一名刚入职的初级开发者，目前遇到一个关于DTO与Model的技术疑问。

当前参与项目的代码实现类似以下片段：

@Override
public ResponseEntity<List<PostalCodeLocationModel>> findPostcalCodeLocationPairs(final PostalCodeLocationSearchModel model) {
    final String postalCode= model.getPostalCode();
    final String location = model.getLocation();

    final List<PostalCodeLocationModel> listOfPostalCodeLocationPairs = service.findPostalCodeLocationPairs(plz, ort).stream()
            .map(mapper::dtoToModel)
            .toList();

    return ResponseEntity.ok(listOfPostalCodeLocationPairs);
}

或者：

@Override
public ResponseEntity<UserReadModel> getUserData(final String name) {
    UserDTO dto = service.getUser(user);
    UserReadModel userReadModel = mapper.dtoToModel(dto);
    return ResponseEntity.ok(userReadModel);
}

我之前学到的知识是Controller层最终应该映射为DTO并返回，但当前项目是把Service返回的DTO转换为Model后返回。想请教这种实现方式是否正确？

我之前项目的实现方式是这样的：

@ApiOperation(value = "Get Enterprises within Radius", notes = "Retrieves enterprises within the given radius from a geographical point")
@GetMapping("/within-radius")
public ResponseEntity<List<EnterpriseDto>> getObjectsWithinRadius(@RequestParam double lat, @RequestParam double lng, @RequestParam double radius) {
    List<Enterprise> enterprises = enterpriseService.getEnterprisesWithinRadius(lat, lng, radius);
    List<EnterpriseDto> enterpriseDtos = enterpriseMapper.toDtos(enterprises);
    return new ResponseEntity<>(enterpriseDtos, HttpStatus.OK);
}

这里是调用Service获取Enterprise对象后，映射为DTO再返回。

首先要明确，这里的核心是命名和职责定义的差异，而非实现对错。

你之前学到的“Controller返回DTO”是常规的分层架构约定：

• 通常Entity（比如你之前项目的Enterprise）对应数据库表结构，是持久层的模型；
• DTO（Data Transfer Object）是专门用于跨层/跨服务传输的数据载体，Controller返回DTO是为了隔离内部模型和对外暴露的数据结构，避免内部字段泄露或因模型变更影响外部接口。

而当前项目里的Model（比如PostalCodeLocationModel、UserReadModel），本质上就是其他项目里的“DTO”，只是团队对这个角色的命名不同而已。这类Model应该是专门为接口输出定义的、只包含对外需要暴露字段的载体，和你之前用的EnterpriseDto职责完全一致。

那为什么会有这种差异？

• 不同团队的命名习惯不同：有些团队把对外传输的对象叫DTO，有些叫Model（甚至VO、Response），核心都是承担数据传输的职责；
• 可能当前项目里的DTO是服务内部各层之间传输的对象，而Model是专门给Controller对外返回用的——这种情况下，相当于把“内部DTO”和“外部DTO”做了拆分，进一步隔离内部逻辑和对外接口，也是合理的设计。

判断这种实现是否正确，看两个关键点：

1. 对外返回的Model是否只包含接口需要的字段，没有暴露内部敏感或无关数据；
2. 内部业务逻辑的变更（比如Service层的DTO结构调整）是否不会直接影响对外接口的返回结构——如果满足这两点，那这个实现就是合理的。

总结：不用纠结命名，重点看职责是否清晰，是否做到了内部模型和对外接口的隔离。当前项目的实现只是命名和你之前的习惯不同，本质上是符合分层架构的设计思路的。

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