一个“根据仓库编号查询库存”的接口,SQL 就十来行,项目里却能落下 Controller、Service、ServiceImpl、Mapper、XML、DTO、VO 一串文件。
接口还没写完,包先建了六个。
这种代码不能说错,分层也确实有价值。但内部报表、运营后台、临时数据查询,全都照这个架势写,我第一眼就觉得累。业务没多少,样板代码倒是一层压一层。
后来我试了一下 Dataway。
它干的事情有点猛:直接把接口配置、SQL 调试、发布放进一个管理页面里。简单接口不用再手写 Controller、Service、DAO、Mapper,配置完成后自动映射成 HTTP API。
官方给它的定位也很直接:Dataway 基于 DataQL 提供接口配置能力,以 Jar 包集成到应用里,接口可以直接在页面中配置和发布。
先把 Hasor 和 Dataway 的依赖放进 Spring Boot,版本不要闭眼抄,先跟项目里的 Spring Boot、JDK 做一次兼容验证。
启动类只多两个注解:
@EnableHasor
@EnableHasorWeb
@SpringBootApplication
public class StockCenterApplication {
public static void main(String[] args) {
SpringApplication.run(StockCenterApplication.class, args);
}
}
然后把 Spring 管理的数据源交给 Hasor。这里我不建议再单独创建一套连接池,两边各玩各的,出了连接耗尽还得查半天。
@DimModule
@Component
@RequiredArgsConstructor
public class DatawayDatasourceBridge implements SpringModule {
private final DataSource businessDataSource;
@Override
public void loadModule(ApiBinder binder) {
JdbcModule jdbc = new JdbcModule(Level.Full, businessDataSource);
binder.installModule(jdbc);
}
}
配置里开启 Dataway:
HASOR_DATAQL_DATAWAY=true
HASOR_DATAQL_DATAWAY_ADMIN=true
HASOR_DATAQL_DATAWAY_API_URL=/open-api/
HASOR_DATAQL_DATAWAY_UI_URL=/dataway-ui/
应用启动后进入管理页面,新建一个 GET 接口:
/inventory/list
原来需要塞进 Mapper XML 的 SQL,可以直接写在接口脚本里:
select
id,
sku_code,
sku_name,
available_qty,
updated_at
from inv_sku_stock
where warehouse_id = #{warehouseId}
and deleted = 0
and (
#{keyword} is null
or sku_name like concat('%', #{keyword}, '%')
)
order by updated_at desc
limit 100
填入warehouseId和keyword,页面里直接调试。结果对了,点发布,接口就能访问。
这时候项目里没有新增 Controller,也没有 ServiceImpl,更没有一份只写了一个方法的 Mapper。Dataway 会读取请求参数、执行脚本,再把结果转成 HTTP 响应。查询、表单提交、数据聚合这类接口,确实能省掉不少重复代码。官方文档列出的主打场景也主要是取数、存数和数据聚合。
不过看到这里,别急着把整个项目的 Controller 都删了。
这种工具我会用,但只会放在合适的位置。
后台列表、统计报表、配置查询、临时运营接口,这些逻辑短、变化快、事务要求不高,用 Dataway 很顺手。需求上午改字段,下午就能发布,不必重新编译整个应用。
但订单创建、支付回调、库存扣减、复杂权限、跨服务编排,我不会往里面硬塞。
这些接口要处理事务边界、幂等、审计、异常补偿和领域规则。脚本短的时候看着痛快,等判断堆到几十行,维护体验未必比 Service 好。到时候 Controller 是没了,业务逻辑却变成一坨藏在管理页面里的脚本,更难查。
还有一个配置必须盯死:
# 生产环境关闭接口管理页面
HASOR_DATAQL_DATAWAY_ADMIN=false
官方文档也明确提醒,生产环境开放管理功能会带来严重安全风险。
除此之外,接口脚本最好纳入版本管理,发布前做 SQL 审核,限制查询行数和执行时间。慢 SQL 还是慢 SQL,不会因为它没写在 Mapper.xml 里就突然变快。
所以这工具绝的地方,不是把 Spring Boot 的分层架构干掉了。
它只是把那批“明明一条 SQL 就能解决,却要创建七八个文件”的接口,从 Java 工程里拎了出来。
该省的代码省掉,该守的边界别动。这样用,确实舒服。