Spring-hasor, spring和hasor整合

是派大大欣

已于 2023-09-12 10:03:47 修改

阅读量161

点赞数

分类专栏： Hasor 文章标签： spring java 后端

于 2023-09-12 10:02:05 首次发布

本文链接：https://blog.csdn.net/Cynthia018/article/details/132763518

版权

Hasor 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Spring-hasor, spring和hasor整合

背景
介绍
- Hasor 介绍
- Dataway介绍
调研
其他

背景

近期的工作主要是NLP项目，新的项目有三十多个表，每个nlp表数据都要提供对外api，仅通用的增删改查算都100+个接口，单个接口研发工作量非常大。而Hasor能让SpringBoot不需要Controller、Service、DTO、PO、VO、Mapper这听能够节省我不少工作量。

介绍

Hasor 介绍

Hasor官方
官网的部分简介
Hasor是一个完整的框架体系，它独有的框架扩展能力可以使新的能力完全无缝的集成到统一的 API 体系中。我们就只需要扩展 Hasor，而得到我们所需要的接口，而不需要向核心框架添加每个特性。

Hasor 的扩展能力更像是一个乐高玩具的接口，任何人都可以通过非常简单的方式提供乐高积木，然后轻松的将它们融合到一起。在使用的过程中完全感受不到背后是多个不同的框架在协作。

Hasor 的目标是使开发和调试变得更容易和更快。

Dataway介绍

dataway官方
Dataway 是基于 DataQL 服务聚合能力，为应用提供的一个接口配置工具，使得使用者无需开发任何代码就配置一个满足需求的接口。整个接口配置、测试、冒烟、发布，一站式都通过 Dataway 提供的 UI 界面完成。UI 会以 Jar 包方式提供并集成到应用中并和应用共享同一个 http 端口，应用无需单独为 Dataway 开辟新的管理端口。

在这里插入图片描述
Dataway 工具化的提供 DataQL 配置能力。这种研发模式的变革使得，相当多的需求开发场景只需要配置即可完成交付。从而避免了从数据存取到前端接口之间的一系列开发任务，例如：Mapper、BO、VO、DO、DAO、Service、Controller 统统不在需要。

调研

我为什么要调研这个框架呢？

最开始在出这三十二个表的查询列表接口和查询详情接口时，还没使用hasor。写每个接口都要先写Mapper类，再根据输入和输出的要求创建对应的PO、VO、DTO类，还要打开数据库一个个复制这个表的字段名，下划线改驼峰，感觉我的左手小拇指都焊死在ctrl键上了。以及疯狂的、重复性的敲private String。这是一种及其无聊且没有难度的重复性活动。
加上，最近需要给其他项目组提供接口，而对方需要的接口都是非常简单的查询数据库接口，比如select * from tableA, select english_name from tableB where id = 1。这种接口一下就要出五个，一个个的写效率非常低，而我又只是需要将数据库查到的结果反馈给其他项目组的开发人员。

主打场景

取数据：如果你只想从数据库或者服务中获取某类数据，不需要：VO、BO、Convert、DO、Mapper 这类东西。

存数据：如果是从页面表单递交数据到数据库或者服务，免去 BO、FormBean、DO、Mapper 这类东西。

数据聚合：基于服务调用结果经过结构转换并响应给前端。将数据库和服务等多个结果进行汇聚然后返回给前端。

优缺点

知道这个框架后安排了些时间，在原有服务上添加了Hasor依赖试了一下。
优点：

避开 COC 原则的原因是， COC 虽然已约定的方式降低了整个框架的设计复杂度；

Convention over Configuration（CoC）– 惯例优于配置原则
简单点说，就是将一些公认的配置方式和信息作为内部缺省的规则来使用。例如，Hibernate的映射文件，如果约定字段名和类属性一致的话，基本上就可以不要这个配置文件了。你的应用只需要指定不convention的信息即可，从而减少了大量convention而又不得不花时间和精力啰里啰嗦的东东。配置文件很多时候相当的影响开发效率。