思来想去!可能与 Solon 容器的独立设计有一定关系。
1、Solon 注解容器的运行特点
- 有什么注解要处理的(注解能力被规范成了四种),提前注册登记
- 全局只扫描一次,并在扫描过程中统一处理注解相关
- 扫描注入时,目标有即同步注入,没有时则订阅注入
- 自动代理。即自动发现AOP需求,并按需动态代理
2、内部结构示意图
3、支持四种注解能力的处理对象:
对象 | 说明 |
---|---|
BeanBuilder | 构建器(比如:@Component 注解,如果没有注册此注解的构建器,则会无视) |
BeanInjector | 注入器(比如:@Inject、@Db、@CloudConfig、@VaultInject) |
BeanExtractor | 提取器(比如:@Scheduled、@CloudJob) |
BeanInterceptor | 拦截器(比如:@Tran、@Cache) |
Solon Aop 的具体表象:即为注解处理,原则上需要提前埋好切点(不支持表达式 Aop)。开发及应用可见《四种自定义注解开发汇总》
4、关于自动代理
当一个组件(即 @Component
注解的类),其函数上的注解有对应的拦截处理时(即有 AOP 的需求)。此组件会启用动态代理。关于代理,可参考《动态代理的本质》。v2.5.3 后支持
5、容器处理的补充
- 比如有些需要拼装的活,可以交给配置器("@Configuration" 注解的类)去处理
- 或者需要初始化的活,交给生命周期的类("LifecycleBean" 接口实现的组件或 "@Init" 注解函数)去处理
- 再可借助 事件总线 + 应用生命周期 做些事情