日常开发中,最繁琐的便是编写 Controller。很多公司都制定了规范:Controller 不能存在任何的业务逻辑,主要完成参数解析和结果转换。
不过查看项目源码,你会发现 Controller 中存在了大量不该存在的逻辑,对此,你有什么好的方法?依赖 Code Review?从我角度,我觉得 Controller 根本就不需要存在。
之前对 CommandService
和 QueryService 进行封装,通过定义接口的方式快速搭建应用服务,大大提升了开发效率和代码质量,在有了应用服务之后,便是在其基础之上编写 Controller,把能力暴露出去。这是一个非常繁琐且没有技术含量的重复工作。而对于枯燥的重复工作,我的策略一直都是“交由框架完成”。
简单的说,我们的目标便是不写Controller,但还要保留 Controller 的效果。
CommandService
和 QueryService 直接暴露为 Web 接口;首先,在 pom 中增加 lego-starter,具体如下:
<dependency>
<groupId>com.geekhalo.lego</groupId>
<artifactId>lego-starter</artifactId>
<version>0.1.11-rest-SNAPSHOT</version>
</dependency>
其次,增加 swagger 相关依赖,具体如下:
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-boot-starter</artifactId>
<version>3.0.0</version>
</dependency>
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-data-rest</artifactId>
<version>3.0.0</version>
</dependency>
最后,新建 SpringFoxConfiguration
,启用 Swagger 具体如下:
@Configuration
@EnableSwagger2
public class SpringFoxConfiguration {
}
打开浏览器,输入 http://127.0.0.1:8080/swagger-ui/
打开 swagger 界面,会发现新增两个 Controller:
command-dispatcher-controller
是对 CommanderService
的Web暴露,主要用于执行写入和更新等业务操作,两个接入点包括:
query-dispatcher-controller
是对 QueryService 的Web暴露,主要用于执行业务的查询操作,同样支持 RequestBody 和 RequestParam 两种接入方式。与 command-dispatcher-controller
唯一区别是提供了对 Get 方法支持。
但在展开方法后,有点让人绝望。
serviceName 和 method 两个参数从哪获取?nativeRequest 和 nativeResponse 又是什么东西?这两个接口怎么使用?
看不明白也正常,因为我们不会直接使用这两个处理器。
在 OrderCommandService
接口上增加 @AutoRegisterWebController
注解,将其对外暴露为 Web 端口。
@CommandServiceDefinition(
domainClass = Order.class,
idClass = Long.class,
repositoryClass = OrderRepository.class)
@AutoRegisterWebController(name = "order")
public interface OrderCommandService{
void cancel(Long orderId);
Long create(CreateOrderCommand command);
void paySuccess(PaySuccessCommand command);
}
输入 http://127.0.0.1:8080/swagger-ui/
访问 swagger 界面,发现新增一组 Controller。
OrderCommandService
服务中的所有方法全部出现在 Controller 中。
首先,展开 CommandByBody
中的 create 方法,可见:
然后,展开 CommandByParam
中的 create 方法,具体如下:
整体结构和手写 Controller 基本一致,所暴露的功能也全部相同。
在 OrderQueryService
接口上增加 @AutoRegisterWebController
注解,将其对外暴露为 Web 端口。
@QueryServiceDefinition(domainClass = Order.class,
repositoryClass = OrderQueryRepository.class)
@Validated
@AutoRegisterWebController(name = "order")
public interface OrderQueryService {
OrderDetail getById(@Valid @NotNull(message = "订单号不能为null") Long id);
Page<OrderDetail> pageByUserId(@Valid @NotNull(message = "查询参数不能为 null") PageByUserId query);
List<OrderDetail> getByUserId(@Valid @NotNull(message = "查询参数不能为 null") GetByUserId getByUserId);
Long countByUser(@Valid @NotNull(message = "查询参数不能为 null") CountByUserId countByUserId);
List<OrderDetail> getPaidByUserId(Long id);
}
输入 http://127.0.0.1:8080/swagger-ui/
访问 swagger 界面,发现新增一组 Controller。
OrderQueryService
服务中的所有方法全部出现在 Controller。
首先,展开 QueryByBody 中的 pageByUserId
方法,可见:
然后,展开 QueryByParam 中的 pageByUserId 方法,具体如下:
入参与返回值结构非常清晰,整体结构和手写 Controller 基本一致,所暴露的功能也全部相同。
整个设计分为两部分:
提供 QueryDispatcherController
作为所有查询请求的入口,核心架构如下:
初始化流程如下:
QueryService Bean
自动注册到 QueryServicesRegistry
;QueryMethodRegistry
从 QueryServicesRegistry
中获取服务实例,对 QueryMethod 进行解析,并完成注册;执行流程如下:
QueryDispatcherController
的相关方法;QueryDispatcherController
根据 serviceName 和 methodName 从 QueryMethodRegistry
中获取 QueryMethod,执行业务方法,最后返回最终结果;提供 QueryServicesProvider
与 Swagger 进行集成,提供完整的 api doc,整体设计如下:
QueryServiceProvider
与 QueryDispatcherController
一致,同样依赖于 QueryMethodRegistry
中的 QueryMethod 信息。
核心流程如下:
QueryServicesProvider
从 QueryMethodRegistry
中获取 QueryMethod 信息;RequestHander
,并注册到 Swagger ;RequestHander
转化为 api doc进行返回;网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。
加入交流群
请使用微信扫一扫!