哪一层最适合 Java DTO 的映射器、服务层或控制器层？ [关闭]答案

【问题标题】：Which one layer fits best for Java DTO's mappers, Service layer or Controller layer? [closed]哪一层最适合 Java DTO 的映射器、服务层或控制器层？ [关闭]
【发布时间】：2018-04-28 19:57:59
【问题描述】：

最近我开始思考@Transactional 以及它的工作原理和性能，并且我有一个使用spring 事务的项目，所以我有这样的代码：

@Transactional
public PageableProductsDTO getUsersProducts(String userName, Pageable page) {
    PageRequest pageRequest = PageRequest.of(page.getPageNumber(), page.getPageSize(), Sort.Direction.DESC, "createdAt");
    Page<Product> pagebelProductsByUser = productRepository.findProductsByUser(userService.getUser(userName), pageRequest);
    Page<ProductDetailsDto> productDtos = pagebelProductsByUser.map(source -> {
        ProductDetails productDetails = source.getProductDetails();
        return new ProductDetailsDto(productDetails.getBarcode(), productDetails.getName(), productDetails.getPrice());
    });
    return new PageableProductsDTO(productDtos);
}

如您所见，在上面的方法中，我从db中获取产品，然后将产品映射到PageableProductsDTO，我怀疑我是否做对了，因为可能dto映射应该是在控制器层完成？而且似乎在服务层做这样的映射会延长事务本身花费的时间，我的意思是从性能的角度来看可能不是很好？

【问题讨论】：

标签： java spring spring-transactions dto

【解决方案1】：

没有万能的解决方案，只有最适合您的解决方案。这不是关于 DTO 是模式还是反模式，而是关于你是否需要它们......以及为什么

问题的一部分是您是否应该在 controller 或 service 层中重新打包数据。这完全取决于您是否引入了 DTO 来分离应用程序层的数据和业务逻辑或您是否引入了 DTO 来重新打包将返回给客户端的数据（可能会删除一些私有属性）（如果是后者，则由控制人负责）。

虽然在这种情况下对性能的影响看起来可以忽略不计，但您应该¹在单独的方法中移动从数据库加载数据的逻辑，并将其标记为事务性²。

¹ 方法分离将允许您在服务层内重用从数据库加载数据的代码，而无需将数据重新打包回实体。

²只要您想在执行 db load 后提交事务，这将是一个很好的模式。如果您想重用从数据库加载数据的方法，请考虑其他用例以及如果您想延长提交时间。

【讨论】：