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

Java 中 Service 层不直接返回 Result 对象,主要基于分层架构的职责分离原则: 职责清晰:Service 层专注业务逻辑,Controller 层负责响应封装,避免业务与表现层耦合. 提高复用性:Service 方法可Neng被其他 Service 调用,返回 Result 需额外解包,增加复杂度.

@Servicepublicclass UserService {    public Result<User> getUserById {        User user = userMapper.selectById;        if  {            return Result.error;        }        return Result.success;    }}@RestControllerpublicclass UserController {    @Autowired    private UserService userService;        @GetMapping    public Result<User> getUser {        return userService.getUserById;    }}

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

说实话，咱就是说这种写法有点不太对劲。

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

@RestController@RequestMappingpublicclass UserController {        @Autowired    private UserService userService;        // REST接口返回Result    @GetMapping    public Result<User> getUser {        User user = userService.getUserById;        return Result.success;    }        // GraphQL接口直接返回对象    @QueryMapping    public User user {        return userService.getUserById;    }        // RPC接口返回自定义格式    @DubboService    publicclass UserRpcServiceImplimplementsUserRpcService {        public UserDTO getUserById {            User user = userService.getUserById;            returnconvertToDTO;        }    }}

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

害，你kan，这样一来灵活性不是geng好吗？

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

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

你懂的，结果对象是基础设施层的概念，不应该污染领域层。

@Testpublic voidtestGetUserById {    // 不推荐的方式:需要解包Result    Result<User> result = userService.getUserById;    assertTrue);    assertNotNull);    assertEquals.getName);}

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

不对不对，应该是说这样写会导致业务逻辑和表现逻辑混在一起。

Zui近我在想，为什么有些文章不收录，其实是有原因的，你得让搜索引擎觉得你的内容有价值才行。

比如说你的内容太单薄，或者没有解决实际的问题，就hen容易被忽略掉。

为啥呢？因为Ru果 Service 返回的是 Result，hen难界定事务是否应该回滚。

@ServicepublicclassOrderService {    @Autowired    private UserService userService;       public void createOrder {        // 推荐的方式:直接获取业务对象        User user = userService.getUserById;               // 后续业务逻辑        validateUserStatus;        // ...    }}

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

@RestControllerAdvicepublicclassGlobalExceptionHandler {    @ExceptionHandler    public Result<Void>_handleBusinessException {        returnResult.error);    }       @ExceptionHandler       public Result<Void>_handleException {        log.error; // 这里Ke以查kan堆栈信息               returnResult.error;       }}

这样Zuo的好处是减少重复代码，让业务方法geng专注于业务逻辑，而不是处理响应格式。

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

@Servicepublicclass UserService {       public User getUserById {        User user = userMapper.selectById;               if {            throw new BusinessException;               }               returnuser;       }}@RestControllerpublicclass UserController {       @Autowired       private UserService userService;              @GetMapping       public Result<User>getUser {               User user = userService.getUserById;               returnResult.success;       }} 结论

让每一层dou专注于自己的职责，才Neng写出geng优雅的代码！

@SpringBootTestpublicclass UserSerivceTest {   @Autowired   private UserSerivce userSerivce;   @Test   public void testGetUSerByID{       //推荐的方式：直接断言业务对象       USer u=serivce.getUSerBYID;       assertNotNull;       ...   }   @Test   public void testGetUSerBYID_notFound{       //推荐的方式：断言抛出异常       assertThrows->{           uSerivce.getUSerBYID;       });   } }

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

为啥这样不好呢？你想啊，Ru果 Service 返回的是 Result，那么 Controller 就不需要再Zuo额外的处理了但这样会导致业务逻辑和响应格式耦合在一起。

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

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

publicvoidcreateOrder{   if{       thrownewBusinessExcepiton;   }   后续的具体的实现.... }

通过全局异常捕获来转换为 Result，这样Ke以保持业务逻辑的纯粹性，同时也Neng满足不同接口的需求。

为啥要这么Zuo呢？因为这样Ke以让每一层dou专注于自己的职责，保持代码的可复用性和可维护性。

昨天在 Code Review 时我发现阿城在 Sercice 曾 直接 返回 了 REsult 对象。

于是我们展开了一场技术讨论。

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

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

知其然geng知其所以然。耐心kan完，你一定有所收获。