前阵子，我写了一篇关于《为什么 Java 里面Service 层不直接返回 Result 对象？》的文章。说实话，我没想到那篇文章的讨论度会那么高。评论区里有人赞同我的观点，觉得分层清晰才是王道；也有不少人持反对意见，觉得为了分层而分层，Zui后写一堆只有转发作用的代码，纯属是在浪费生命。

这背后其实反映出一个hen实际的工程问题：我们一边在口头上强调分层的重要性，一边又在大量的 Controller 里重复着几乎没有业务价值的样板代码。这种矛盾，就像是你明明想吃健康的减脂餐，结果外卖送来的全是裹着厚厚面糊的炸鸡——虽然Neng填饱肚子，但总觉得哪里不对劲。

于是我顺着这个问题，尝试着往前走了一步，Zuo了一个开源框架：ArcRoute。GitHub 仓库地址是：wuuJiawei/ArcRoute。Ru果你也厌倦了日复一日地复制粘贴 Controller 代码，不妨坐下来听听这个框架是怎么试图解决这个“老大难”问题的。

当 Controller 变成“空心层”，我们该怎么办？

在hen多项目里之所以 Service 层Zui后开始直接返回 Result，是因为开发者在漫长的代码维护过程中，开始嫌麻烦，Zui终选择了妥协。毕竟Ru果你坚持“Service 不直接返回 Result”，那hen多 Controller Zui后就会变成这个样子：

@GetMapping
public Result getUser {
    UserDTO dto = userService.getUser;
    return Result.success;
}

几十个、几百个接口，结构dou一样。这种代码，kan久了真的会觉得有些无聊，甚至让人产生一种自我怀疑：我作为一个受过专业训练的工程师，每天的工作就是在这些方法之间搬运数据吗？

hen多人第一次kan到这种设计，心里可Neng会冒出一个疑问：“这不就是把 Controller 换了个写法吗？”

表面上kan，好像是。但本质上，ArcRoute Zuo的是两件事：它把没有业务承载价值的 Controller 样板，统统收敛到框架里；同时它让业务代码专注业务，接口代码专注接口，把重复劳动交给了机器。

ArcRoute 的核心思路：接口即契约

ArcRoute 的核心思路，其实Ke以概括成一句话：业务归业务，接口归接口。

在传统的 Spring MVC 写法里路由声明、参数注解、实现逻辑dou堆在一个类里。而在 ArcRoute 的设计哲学里HTTP 接口不再必须写在 @Controller 或 @RestController 里而是Ke以定义在接口上。

这意味着，接口定义本身geng像一个清晰的契约，而不是一堆 Controller 方法里的杂糅细节。比如你Ke以这样定义你的 API：

@Api
public interface UserApi {
    @ApiRoute
    UserDTO getUser Long id);
    @ApiRoute
    Result createUser;
}

然后你的业务实现只需要老老实实写在实现类里就行了：

@ApiService
@Service
public class UserApiImpl implements UserApi {
    @Override
    public UserDTO getUser {
        return userService.findById;
    }
    @Override
    public Result createUser {
        return Result.ok);
    }
}

框架会在启动时扫描这些注解，自动完成路由注册、参数绑定、校验、调用分发等工作。你不需要为了维持分层，额外写一堆机械代码；框架Yi经把路由、绑定、校验、调用分发这些动作Zuo掉了。业务实现就安安心心写业务逻辑，这才是我们该有的工作状态，对吧？

一条清晰的调用链：不仅仅是路由

有人可Neng会问，ArcRoute 不就是一个路由扫描器吗？其实不然。ArcRoute 不只是一个路由扫描器，而是围绕接口层Zuo了一套完整的Neng力编排。

它内置了一条统一调用链，我们Ke以把它想象成一条流水线：参数解析 → 校验 → 前置处理 → 业务调用 → 后置处理 → 响应包装。

这意味着，hen多原本散落在各个 Controller、Advice、Interceptor 里的重复逻辑，Ke以被整合成一条清晰、可插拔的管道。比如统一鉴权、参数校验、审计、异常转换、接口级 ，这类需求一多，传统 Controller 写法hen容易散，而 ArcRoute 的处理器机制和调用链模型，会geng有组织性。

它支持 ApiPreProcessorApiPostProcessorApiExceptionProcessor，还支持用 @ApiPipeline 在接口级或方法级挂载处理器和校验器。不吹牛的说这种设计既保持了灵活性，又有统一归口。

强大的参数绑定Neng力

在参数处理这块，ArcRoute 也下足了功夫。它支持 @Path@Query@Header@Body@Part@Cookie@Ctx 等参数绑定方式。甚至，Ru果你需要，它还支持直接注入 HttpServletRequestHttpSessionPrincipalLocale 这类原生参数。

当然它也完美支持 Bean Validation，校验逻辑完全不需要你操心。

响应包装的自由度

关于响应包装，ArcRoute 提供了 @WrapResult 注解来自动包装返回结果，同时也支持通过 @RawResponse 跳过包装。考虑到不同团队的 Result 结构dou不同，ArcRoute 也支持自定义返回的响应体结构。

甚至，Ru果你需要返回 ResponseEntity 或者 SseEmitter 这样的原生响应，当然也完全没问题，直接用 @RawResponse 就行。

它不是银弹，但它是把好刀

强调一下：ArcRoute 不是银弹，任何技术方案dou不是银弹。我从来不觉得技术是为了整活，也不是为了重新发明 Spring MVC。ArcRoute 本质上就是给这类团队一个工程化解法。

Ru果你的接口层本身就有大量自定义流程，Controller 不是空心层，那 ArcRoute 的优势确实会变小。毕竟Ru果就十来个接口，手写 Controller 完全不是问题，没必要为了优雅再加一层抽象，那是过度设计。

但是Ru果你的项目符合以下情况，那这个框架也许值得你驻足：

接口数量庞大： 几十个、几百个接口，结构高度雷同，充满了机械劳动。

关注点分离强迫症： 你真的认同职责分离，不想让 Service 层被 HTTP 协议的细节污染。

团队协作规范： 你希望接口定义像契约一样清晰，而不是埋在实现细节里。

这类项目Zui典型的代码就是那种除了转发参数、包装一下 Result 之外什么dou没有的 Controller。这种情况下用 ArcRoute 把重复代码提走，收益会非常明显。

渐进式接入：给团队一点缓冲时间

我想，对团队来说渐进式接入，才geng容易真正落地。ArcRoute 的思想不复杂，但它毕竟不是大家Zui熟悉的 Spring MVC 默认写法，团队需要一点接受成本。

所以老项目不必推倒重来。你Ke以先在新接口上尝试，或者慢慢重构旧接口。这比较符合真实项目的演进路径。一个项目想要真正成长起来还需要越来越多人在真实项目里去使用、去反馈、去批评。

Ru果你想尝试一下Ke以直接引入 Starter 依赖：

    pub.lighting
    arcroute-spring-boot-starter
    0.0.1 

写在Zui后

上一篇文章是在回答“为什么不该这么写”；而 ArcRoute 是在回答“那怎样写，才不痛苦”。

一旦 Service 和 HTTP 响应格式绑死，业务层就hen容易被表现层污染。ArcRoute 把这两部分拆开了它把 “Keeping Services Focused” 直接写进了仓库描述里这个定位其实和上一篇文章是一脉相承的。

我觉得 ArcRoute Zui适合宣传的一点，不是“Neng少写 Controller”，而是：它让接口Ke以geng清晰地作为“契约”存在而不是埋在实现细节里。README 也把这一点列为核心特性之一：接口声明与实现分离，API 定义在 Interface，业务在 Impl。

Ru果你正在Zuo Spring Boot 项目，又对“Controller 样板太多、Service 职责容易漂移”这件事感到烦，那这个项目也许值得你驻足。还是保留了分层思想，但不需要再手写胶水代码。

只是想把一件我hen在意的事，Zuo得再顺畅一点。Ru果你也认同，欢迎去kankan ArcRoute，也欢迎来提 Issue、提建议、提反例。毕竟没有另起炉灶，只是想让开发体验变得geng美好一点点。

---