前言
磨了许久,借助最近的一次通宵上线 cicada终于更新了 v2.0.0 版本。
之所以大的版本号变为 2,确实是向下不兼容了;主要表现为:
- 修复了几个反馈的 bug。
- 灵活的路由方式。
- 可拔插的 IOC容器选择。
其中重点是后面两个。
新的路由方式
先来看第一个:路由方式的更新。
在之前的版本想要写一个接口必须的实现一个 WorkAction;而且最麻烦的是一个实现类只能做一个接口。
因此也有朋友给我提过这个 issue。

于是改进后的使用方式如下:

是否有点似曾相识的感觉😊。
如上图所示,不需要实现某个特定的接口;只需要使用不同的注解即可。
同时也支持自定义 pojo, cicada 会在调用过程中对参数进行实例化。
拿这个 getUser 接口为例,当这样请求时这些参数就会被封装进 DemoReq 中.
http://127.0.0.1:5688/cicada-example/routeAction/getUser?id=1234&name=zhangsan
同时得到响应:
{"message":"hello =zhangsan"}实现过程也挺简单,大家查看源码便会发现;这里贴一点比较核心的步骤。
- 扫描所有使用 @CicadaAction注解的类。
- 扫描所有使用 @CicadaRoute注解的方法。
- 将他们的映射关系存入 Map中。
- 请求时根据 URL去Map中查找这个关系。
- 反射构建参数及方法调用。
扫描类以及写入映射关系

请求时查询映射关系

反射调用这些方法

是否需要 IOC 容器
上面那几个步骤其实我都是一把梭写完的,但当我写到执行具体方法时感觉有点意思了。
大家都知道反射调用方法有两个重要的参数:

- obj方法执行的实例。
- args..自然是方法的参数。
我第一次写的时候是这样的:
method.invoke(method.getDeclaringClass().newInstance(), object);然后一测试,也没问题。
当我写完之后 review 代码时发现不对:这样这里每次都会创建一个新的实例,而且反射调用 newInstance() 效率也不高。
这时我不自觉的想到了 Spring 中 IOC 容器,和这里场景也非常的类似。
在应用初始化时将所有的接口实例化并保存到 bean 容器中,当需要使用时只需要从容器中获取即可。
这样只是会在启动时做很多加载工作,但造福后代啊。
可拔插的 IOC 容器
于是我打算自己实现一个这样的 bean 容器。
但在实现之
