–从端点科技内部框架Trantor过渡回Spring的记录
记录开发框架 “川坨” 以及对未来Spring开发影响笔记
# 序
既然现在在公司用过了川坨, 看到了Trantor的特性, 如何将其运用到之后的开发中去呢?
下面分多区域介绍从Trantor回到Spring过程中的想法, 上半是Trantor部分, 下半是对Spring个人开发的借鉴
肯定有一些地方是"硬"不互通的, 那部分只能抛下了
# 后端
在老川坨的范畴中, 后端内容Trantor之外就是Spring, 只要Trantor没覆写的地方Spring都可用
# Entity
这部分其实差别不大, 一些繁文缛节
一些开发思想是不错的, 比如
- 逻辑无法实现就加字段 (加非持久化字段, 也就是不和数据库关联的字段)
- 非持久化字段转移到DTO, VO里面, 这部分字段直接在后端返回前端时候计算得出, 不要落库提升大量SQL的性能
# DAO(Mapper)层
说习惯了, DAO(Mapper)层 就是写SQL那个层
TSQL实际上就移到了Service里面, 和我写EduExch时候在MP的操作很像 [当然, 后续项目做大了我还是会把SQL拆到DAO层里面的)
数据库操作的那些拼接SQL的操作, 从之前的QW这种转移到了拆分的形式, 我觉得这种代码风格是不错的(或者说是, 可以接受的), 感觉上类似MP, 实际上应该是JOOQ的语法(虽然之前没用过)
整体写法在臃肿和单薄之间落子, 并有多套实现 (DSL, TSQL, 直接SQL), 全部用TSQL仿照MP那种去拼LambdaQueryMapper还是很快上手的, 拼SQL更不在话下
那么相较于Spring Boot + MP(我的开发环境) 来说, 去掉了mapper区域合并到DAO包(mapper包), 同样有类似的复用方式(直接用类为单位组合为 @Repository + SQL入参 进行调用复用) , 等于省去了可能的mapper使用, 同时在完成基础CRUD的任务目标下基本没有差别
但是一些复杂SQL的处理有bug, 从稳定性角度来说还需要提升 (例如级联和LeftJoin等不能同时存在这样的东西太难受了, 不如不用)
我还是选MP那一套作为自己的持久层框架, 那么TSQL这些就完全派不上用场…但是把它当做JOOQ的话, 对于扩大自己的见识面是很有帮助的
# Service层
这部分没什么好说的, 完全就是Spring那套, 加一些繁文缛节
这里框架与代码风格本身以及在具体业务点中学到的东西并不算在这个"出川坨记"的话题中, 可见另一篇<临川浮梦>
但是Flow + Func两级的Service操作可以借鉴下, 比如一整个大的下单流程可以拆成多个小Service套在大Service里面. 个人之前的Service写的很死板, 就是几个实体类几个Service来按照MP那一套走. 自己可以定义一两个大的Service.
# Controller层
这部分就完全被所写的"前端"XML + TS给取代掉了, 不过个人日常编程中Controller基本就走一个流程, 里面的内容大部分就是一行两行Service层的方法调用.
那么Trantor这里用Flow + Func 两级(Flow可以理解为很多个Func)来替换了这个部分. 虽然个人因为之前TS/JS技艺不精所以不喜欢在川坨的"Controller", 也就是TS里面去处理前端页面传递进来的参数和环境, 但是不得不说TS在这个位置能干很多事情. (大佬们的实现真是眼花缭乱, 直接后端骑脸前端独当一面)
调用方法, 传递参数, 批量设置入参Field, 这些功能都能在Controller进行.
遵照前后端分离模式 + SpringMVC + SB的话, 这部分就完全派不上用场了
# 前端
其实算是"前后端结合"的前端, 实际上由低代码中台负责处理
# XML自动化协议生成
我们说写前端其实不是写前端, 只是在XML传控制数据, 前端接收后解析, 解析完毕了根据拿到的索引去查找对应的元素并在对应位置出现而已.
因此并不是前端, 只能说是一个低代码中台做的事情. 并且这个前端还包含TS的处理, 实际上是写一个脚本, 类似这个感觉. 只是做一些数据展示的处理, 并且封装搜集数据并调后端接口.
真正的前端是有的, 但是"门槛"很高. 看来是处理一些客制化定制的东西, 类似于直接开发Vue的小组, 把这些组件和关联关系对应起来.
其实这整个实现的逻辑和前后端不分离时候使用的模板引擎很像, 例如freemarker, 就是这样用插值表达式直接在后端写的
是的, XML很无趣: Trantor开发不需要写前端? nono, 我们不过是一次把前端都写完了, 然后后端通过XML把窟窿填补罢了, 就和平常的Controller没有什么意思上的变化, 返回一些结构化数据. 前端接受后解析对应资源, 一个萝卜一个坑的把对应位置的组件放进去, 再把数据拿进去放着就完了.
至于TS, 不过是把一些逻辑给了前端, 让他work well 罢啦
(毫无疑问, 后面要学还是学Vue3那一套转全栈, 这部分太局限了)
# 页面
页面框架很丑陋, 就是给企业员工做的, 要不得好看, 甚至列表框总是看不完整. 很多交互很狗屎, 并且做的这么丑这么糙了竟然我这种老爷机还跑不起来?! 说明性能狗烂的, 交互响应很烂, 没有异步这些, 都是一个样. 并且页面标签很狗, 拉不完整.
但是也有好的点, 比如说, 确实做到了快速开发, 并且和Trantor这个生态是有保障的. 确实能做到模型直接展示到页面里面去, 前端不需要就可以基本开发. 很好
(毫无疑问, 没有复用的可能)
# 结
本身封装的水平大概中上吧, 能体现阿里平台开发的水平 : 能够完全造出这一套确实挺厉害, 并且没有看到很多JOOQ那些生接口(不是直接调用后台接口, 有针对Trantor的模型字段进行处理的操作)
内部封装的框架, 从观察研究的角度十分吸引人. 虽然可能我的理解只有1/10不到, 但是确实看到了很多东西, 有了许多新的灵感
当然, 从转到Spring的复用角度来说, 结果是差强人意的.
不管怎样, 川坨工程师的皮肤可以卸下了, 背起行囊上路