架构思路:
构建应用框架之时,对框架进行了结构化构思,需要有一层设计,可以为业务公共层服务
Loader的想法,有点像webpack中的加载器,但两者不太一样,有点像hooks但是服务的对象不一样。
设计目的:
1、穿梭与底层框架与业务,服务对象为业务构建运行,为业务公共层服务,应用框架搭建只需要关注管理器提供的API即可,不需要关注内部实现
2、业务功能开发与公共服务隔离,防腐作用
而且这层设计需要具备以下特征:
1、根据运行环境或者配置,可自我管理
- 注册
- 注销
2、具备扩展性
根据业务发展,对公共服务进行提取,纳入到管理器中
3、独立性
从架构设计层,具备复用,业务关联性较低,无逻辑依赖性
设计独白:
听着好像有点那个感觉...挺纠结的...
我时常也在想,是自己在造轮子或者设计能力太低...有点想干不想干的感觉...不自信吗?
会不会对业务造成复杂性和伤害性...
但是,做了比不做好...开动吧...
设计对象
- 系统应用加载器
AppLoader
- 登录加载器
LoginLoader
- 路由加载器
RouterLoader
- 系统异常管理器
ErrorLoader
- 消息中心管理器
IMLoader
- 菜单加载器
MenuLoader
系统应用加载器 AppLoader
提供系统加载入口,对各个服务的加载
- 配置初始化加载
- 系统API接口注册
- 系统异常注册
- 用户中心注册
- 字典注册
- 路由注册
- IM通信注册/连接
登录加载器 LoginLoader
提供应用系统登录的相关能力
- 初始化用户相关数据(菜单、用户、权限等)
- 设置租户/获取租户列表
- 设置/获取/移除/记住用户信息
- 心跳连接监测
- 查询验证码
- 用户注销/退出跳转
- 当前应用跳转/查找默认应用/获取所有子应用/跳转子应用
路由加载器 RouterLoader
- 注册动态路由
- 从内存中加载路由
- 路由拦截/跨应用访问拦截
- 进行页面/退出页面,公共能力逻辑混入
系统异常管理器 ErrorLoader
系统异常监听(HTPP请求、会话失效/重新登录等)--拦截
消息中心管理器 IMLoader
1、IM通信注册
2、创建新连接
菜单加载器 MenuLoader
1、全部菜单获取以及数据结构转换
2、各级菜单获取以及数据结构转换
上述描述的功能,已经实现,目前系统运行良好。
针对Loader管理器的一系列,请看下方:
业务侧-Loader设计构思
业务侧-系统应用加载器-AppLoader
业务侧-登录管理器-LoginLoader
业务侧-异常拦截管理器-ErrorLoader
业务侧-路由管理器-RouterLoader
业务侧-消息管理器-IMLoader
业务侧-菜单管理器-MenuLoader