Java项目中Service 层不直接返回Result 对象的原因分析

更新时间：2026年02月27日 15:00:45 作者：一只叫煤球的猫

在Service层直接返回Result对象会导致业务逻辑与表现逻辑耦合,降低代码清晰度和可维护性,正确的做法是让每一层专注于自己的职责,保持代码可复用性,这篇文章给大家介绍为什么Java里面,Service 层不直接返回Result对象,感兴趣的朋友跟随小编一起看看吧

前言

昨天在Code Review时，我发现阿城在Service层直接返回了Result对象。

指出这个问题后，阿城有些不解，反问我为什么不能这样写。

于是我们展开了一场技术讨论（battle 🤣）。

讨论过程中，我发现这个看似简单的设计问题，背后其实涉及分层架构、职责划分、代码复用等多个重要概念。

与其让这次讨论的内容随风而去，不如整理成文，帮助更多遇到同样困惑的朋友理解原因。

知其然，更知其所以然。

耐心看完，你一定有所收获。

正文

职责分离原则

在传统的MVC架构中，Service层和Controller层各自承担着不同的职责。

Service层负责业务逻辑的处理，而Controller层负责HTTP请求的处理和响应格式的封装。

当我们将数据包装成 Result 对象的任务交给 Service 层时，意味着 Service 层不再单纯地处理业务逻辑，而是牵涉到了数据处理和响应的部分。

这样会导致业务逻辑与表现逻辑的耦合，降低了代码的清晰度和可维护性。

看一个不推荐的写法:

@Service
public class UserService {
    public Result<User> getUserById(Long id) {
        User user = userMapper.selectById(id);
        if (user == null) {
            return Result.error(404, 用户不存在);
        }
        return Result.success(user);
    }
}
@RestController
public class UserController {
    @Autowired
    private UserService userService;
    @GetMapping("/user/{id}")
    public Result<User> getUser(@PathVariable Long id) {
        return userService.getUserById(id);
    }
}

上面代码中，Service 层不仅负责从数据库获取用户信息，还直接处理了返回的结果。

如果我们需要改变返回的格式，或者进行错误信息的标准化，所有 Service 层的方法都需要修改。这样会导致代码的高耦合。

相比之下，以下做法将展示逻辑留给 Controller 层，保证了业务逻辑的纯粹性：

@Service
public class UserService {
    public User getUserById(Long id) {
        User user = userMapper.selectById(id);
        if (user == null) {
            throw new BusinessException(用户不存在);
        }
        return user;
    }
}
@RestController
public class UserController {
    @Autowired
    private UserService userService;
    @GetMapping("/user/{id}")
    public Result<User> getUser(@PathVariable Long id) {
        User user = userService.getUserById(id);
        return Result.success(user);
    }
}

让每一层都专注于自己的职责。

可复用性问题

当Service层返回Result时，会严重影响方法的可复用性。

假设我们有一个订单服务需要调用用户服务:

@Service
public class OrderService {
    @Autowired
    private UserService userService;
    public void createOrder(Long userId, OrderDTO orderDTO) {
        // 不推荐的方式:需要解包Result
        Result<User> userResult = userService.getUserById(userId);
        if (!userResult.isSuccess()) {
            throw new BusinessException(userResult.getMessage());
        }
        User user = userResult.getData();
        // 后续业务逻辑
        validateUserStatus(user);
        // ...
    }
}

这种写法有个很明显的问题。

OrderService 作为另一个业务服务，业务之间的调用本来应该简单直接，但使用 Result 带来了两个问题：

不知道 Result 里到底包含什么，还得去查看代码里面的实现，写起来麻烦。
还需要额外判断 Result 的状态，增加了不必要的复杂度。

如果是调用第三方外部服务，需要这种包装还能理解，但在自己业务之间互相调用时，完全没必要这样做。

如果Service返回纯业务对象:

@Service
public class OrderService {
    @Autowired
    private UserService userService;
    public void createOrder(Long userId, OrderDTO orderDTO) {
        // 推荐的方式:直接获取业务对象
        User user = userService.getUserById(userId);
        // 后续业务逻辑
        validateUserStatus(user);
        // ...
    }
}

代码变得简洁且符合直觉。

业务层之间直接传递业务对象，保持简单和清晰。

异常处理机制

有些 Service 层在业务判断失败后，会直接返回 Result.fail(xxx) 这样的代码，例如：

public Result<Void> createOrder(Long userId, OrderDTO orderDTO) {
    if (userId == null) {
        return Result.fail("用户ID不能为空");
    }
    // 后续业务逻辑
    return Result.success();
}

这种做法有几个问题：

重复的错误处理：每个方法都得写一大堆类似的错误判断代码，增加了代码量。
错误分散：错误处理分散在每个方法里，如果需要改进错误逻辑，要在多个地方修改，麻烦且容易出错。

而如果我们通过抛出异常并结合全局异常处理来统一处理错误，例如：

public void createOrder(Long userId, OrderDTO orderDTO) {
    if (userId == null) {
        throw new BusinessException("用户ID不能为空");
    }
    // 后续业务逻辑
}

再通过全局异常捕获来转换为 Result：

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(BusinessException.class)
    public Result<Void> handleBusinessException(BusinessException e) {
        return Result.error(400, e.getMessage());
    }
    @ExceptionHandler(Exception.class)
    public Result<Void> handleException(Exception e) {
        log.error("系统异常", e);  // 这里可以查看堆栈信息
        return Result.error(500, "系统繁忙");
    }
}

这样做的好处是：

减少重复代码：业务方法不再需要写重复的错误判断，代码更简洁。
集中错误处理：错误处理集中在一个地方，修改时只需修改全局异常处理器，不用改动每个 Service 层方法。
业务与错误分离：业务逻辑专注处理核心功能，错误处理交给统一的机制，代码更加清晰易懂。

而且异常可以携带更丰富的上下文信息，如果业务侧需要时，可以带上堆栈信息，便于一些问题的定位。

测试便利性

Service层返回业务对象而不是Result时，能够大大提升单元测试的便利性:

@SpringBootTest
public class UserServiceTest {
    @Autowired
    private UserService userService;
    @Test
    public void testGetUserById() {
        // 推荐的方式:直接断言业务对象
        User user = userService.getUserById(1L);
        assertNotNull(user);
        assertEquals(张三, user.getName());
    }
    @Test
    public void testGetUserById_NotFound() {
        // 推荐的方式:断言抛出异常
        assertThrows(BusinessException.class, () -> {
            userService.getUserById(999L);
        });
    }
}

如果Service返回Result，测试代码则需要写得更复杂:

@Test
public void testGetUserById() {
    // 不推荐的方式:需要解包Result
    Result<User> result = userService.getUserById(1L);
    assertTrue(result.isSuccess());
    assertNotNull(result.getData());
    assertEquals(张三, result.getData().getName());
}

测试代码变得莫名冗长，还得去关注响应结构，这并不是Service层测试的关注点。

Service 层本应专注于业务逻辑，测试也应该直接验证业务数据。

领域驱动设计角度

再换个角度。

从领域驱动设计（DDD）的角度来看，Service 层属于应用层或领域层，应该使用领域语言来表达业务逻辑。

而 Result 是基础设施层的概念，代表 HTTP 响应格式，不应该污染领域层。

例如，考虑转账业务：

@Service
public class TransferService {
    public TransferResult transfer(Long fromAccountId, Long toAccountId, BigDecimal amount) {
        Account fromAccount = accountRepository.findById(fromAccountId);
        Account toAccount = accountRepository.findById(toAccountId);
        fromAccount.deduct(amount);
        toAccount.deposit(amount);
        accountRepository.save(fromAccount);
        accountRepository.save(toAccount);
        return new TransferResult(fromAccount, toAccount, amount);
    }
}

在这个例子中，TransferResult 是一个领域对象，代表了转账的结果，包含了与业务相关的意义，而不是一个通用的 HTTP 响应封装 Result。

这种做法更符合领域模型的表达，体现了领域层的职责——处理业务逻辑，而不是涉及 HTTP 响应格式的细节。

接口适配的灵活性

当 Service 层返回纯粹的业务对象时，Controller 层可以根据不同的接口需求灵活封装响应：

@RestController
@RequestMapping("/api")
public class UserController {
    @Autowired
    private UserService userService;
    // REST接口返回Result
    @GetMapping("/user/{id}")
    public Result<User> getUser(@PathVariable Long id) {
        User user = userService.getUserById(id);
        return Result.success(user);
    }
    // GraphQL接口直接返回对象
    @QueryMapping
    public User user(@Argument Long id) {
        return userService.getUserById(id);
    }
    // RPC接口返回自定义格式
    @DubboService
    public class UserRpcServiceImpl implements UserRpcService {
        public UserDTO getUserById(Long id) {
            User user = userService.getUserById(id);
            return convertToDTO(user);
        }
    }
}

同一个Service方法可以被不同类型的接口复用，每个接口根据自己的协议要求封装响应。

强行使用 Result 会导致接口的适配性变差，无法根据不同协议的需求灵活定制响应格式。

灵活性反而丢失了。

事务边界清晰

Service 层通常是事务边界所在，当 Service 返回业务对象时，事务的语义更加清晰：

@Service
public class OrderService {
    @Transactional
    public Order createOrder(OrderDTO orderDTO) {
        Order order = new Order();
        // 设置订单属性
        orderMapper.insert(order);
        // 扣减库存
        inventoryService.deduct(orderDTO.getProductId(), orderDTO.getQuantity());
        return order;
    }
}

在这个例子中，事务是围绕 Service 层的方法展开的，@Transactional 注解确保在业务逻辑执行失败时，事务会回滚。因为方法正常返回时，事务会提交；如果抛出异常，事务会回滚，事务的边界非常明确。

如果 Service 返回的是 Result，很难界定事务是否应该回滚。比如：

public Result<Order> createOrder(OrderDTO orderDTO) {
    Order order = new Order();
    // 设置订单属性
    orderMapper.insert(order);
    // 扣减库存
    Result<Void> inventoryResult = inventoryService.deduct(orderDTO.getProductId(), orderDTO.getQuantity());
    if (!inventoryResult.isSuccess()) {
        return Result.fail("库存不足");
    }
    return Result.success(order);
}

在这种情况下，如果库存不足，虽然 Result 返回失败信息，但事务并不会回滚，可能会导致数据不一致，反而还得额外去抛出异常。

而通过抛出异常的方式，事务的回滚语义非常清晰：异常抛出则回滚，方法正常返回则提交，这种设计确保了事务的边界更加明确，避免了潜在的数据一致性问题。

写在最后

到此这篇关于Java项目中Service 层不直接返回Result 对象的原因分析的文章就介绍到这了,更多相关java service 层不直接返回result 对象内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

简单了解SpringBoot过滤器及使用方式
这篇文章主要介绍了简单了解SpringBoot过滤器及使用方式,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
2020-04-04
java Date和SimpleDateFormat时间类详解
这篇文章主要介绍了java Date和SimpleDateFormat时间类详解，文章围绕主题展开详细的内容介绍，具有一定的参考价值，需要的小伙伴可以参考一下
2022-08-08
用Java实现希尔排序的示例
问题：现有一段程序S，可以对任意n个数进行排序。如果现在需要对n^2个数进行排序，最少需要调用S多少次？只允许调用S，不可以做别的操作。我们用希尔排序来做解决这个
2013-11-11
Java实战角色权限后台脚手架系统的实现流程
只学书上的理论是远远不够的，只有在实战中才能获得能力的提升，本篇文章手把手带你用java+Springboot+Maven+myBaits-Plus+Vue+Element-UI+Mysql实现一个角色权限后台脚手架系统,大家可以在过程中查缺补漏，提升水平
2022-01-01
Java实现简单双色球摇奖功能过程解析
这篇文章主要介绍了Java实现简单双色球摇奖功能过程解析,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
2019-09-09
使用JAVA8 filter对List多条件筛选的实现
这篇文章主要介绍了使用JAVA8 filter对List多条件筛选的实现，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
2021-03-03
idea新建springboot项目的方法
这篇文章主要介绍了idea新建springboot项目的方法，文中讲解非常细致，图文并茂帮助大家更好的理解学习，感兴趣的朋友可以了解下
2020-06-06
Java判断对象是否为空的四种方法小结
这篇文章主要介绍了Java判断对象是否为空的四种方法,判断对象是否为空有多种方法,包括使用==或!=运算符直接比较对象与null,使用Objects.isNull()方法,以及用instanceof运算符或Optional类进行更安全的空值处理,需要的朋友可以参考下
2024-10-10
Java设置PDF跨页表格重复显示表头行的步骤详解
这篇文章主要给大家介绍了关于Java设置PDF跨页表格重复显示表头行的相关资料,这里使用的是Free Spire.PDF for Java的jar包,Spire.PDF for Java 是一款专门对 PDF 文档进行操作的 Java 类库,需要的朋友可以参考下
2021-07-07
Java restTemplate发送get请求query参数传递问题解决
这篇文章主要为大家介绍了Java restTemplate发送get请求query参数传递问题解决,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
2023-11-11