前言

磨了許久，藉助最近的一次通宵上線 cicada 終於更新了 v2.0.0 版本。

之所以大的版本號變為 2，確實是向下不相容了；主要表現為：

• 修復了幾個反饋的 bug。
• 靈活的路由方式。
• 可拔插的 IOC 容器選擇。

其中重點是後面兩個。

新的路由方式

先來看第一個：路由方式的更新。

在之前的版本想要寫一個介面必須的實現一個 WorkAction；而且最麻煩的是一個實現類只能做一個介面。

因此也有朋友給我提過這個 issue。

於是改進後的使用方式如下：

是否有點似曾相識的感覺?。

如上圖所示，不需要實現某個特定的介面；只需要使用不同的註解即可。

同時也支援自定義 pojo, cicada

拿這個 getUser 介面為例，當這樣請求時這些引數就會被封裝進 DemoReq 中.

同時得到響應：

{"message":"hello =zhangsan"}

實現過程也挺簡單，大家檢視原始碼便會發現；這裡貼一點比較核心的步驟。

• 掃描所有使用 @CicadaAction 註解的類。
• 掃描所有使用 @CicadaRoute 註解的方法。
• 將他們的對映關係存入 Map 中。
• 請求時根據 URL 去 Map 中查詢這個關係。
• 反射構建引數及方法呼叫。

掃描類以及寫入對映關係

請求時查詢對映關係

反射呼叫這些方法

是否需要 IOC 容器

上面那幾個步驟其實我都是一把梭寫完的，但當我寫到執行具體方法時感覺有點意思

大家都知道反射呼叫方法有兩個重要的引數：

• obj 方法執行的例項。
• args.. 自然是方法的引數。

我第一次寫的時候是這樣的：

method.invoke(method.getDeclaringClass().newInstance(), object);

然後一測試，也沒問題。

當我寫完之後 review 程式碼時發現不對：這樣這裡每次都會建立一個新的例項，而且反射呼叫 newInstance() 效率也不高。

這時我不自覺的想到了 Spring 中 IOC 容器，和這裡場景也非常的類似。

在應用初始化時將所有的介面例項化並儲存到 bean 容器中，當需要使用時只需要從容器中獲取即可。

這樣只是會在啟動時做很多載入工作，但造福後代啊。

可拔插的 IOC 容器

於是我打算自己實現一個這樣的 bean 容器。

但在實現之前又想到一個 feature:

不如把實現 bean 容器的方案交給使用者選擇，可以選擇使用 bean 容器，也可以就用之前的每次都建立新的例項，就像 Spring 中的 prototype 作用域一樣。

甚至可以自定義容器實現，比如將 bean 存放到資料庫、Redis 都行；當然一般人也不會這麼幹。

和 SPI 的機制也有點類似。

要實現上述的需求大致需要以下步驟：

• 一個通用的介面，包含了註冊容器、從容器中獲取例項等方法。
• BeanManager 類，由它來管理具體使用哪種 IOC 容器。

所以首先定義了一個介面；CicadaBeanFactory:

包含了註冊和獲取例項的介面。

同時分別有兩個不同的容器實現方案。

預設實現；CicadaDefaultBean：

也就是文中說道的，每次都會建立例項；由於這種方式其實根本就沒有 bean 容器，所以也不存在註冊了。

接下來是真正的 IOC 容器；CicadaIoc：

它將所有的例項都存放在一個 Map 中。

當然也少不了剛才提到的 CicadaBeanManager，它會在應用啟動的時候將所有的例項註冊到 bean 容器中。

重點是圖中標紅的部分：

• 需要根據使用者的選擇例項化 CicadaBeanFactory 介面。
• 將所有的例項註冊到 CicadaBeanFactory 介面中。

同時也提供了一個獲取例項的方法：

就是直接呼叫 CicadaBeanFactory 介面的方法。

然後在上文提到的反射呼叫方法處就變為：

從 bean 容器中獲取例項了；獲取的過程可以是每次都建立一個新的物件，也可以是直接從容器中獲取例項。這點對於這裡的呼叫者來說並不關心。

所以這也實現了標題所說的：可拔插。

為了實現這個目的，我將 CicadaIoc 的實現單獨放到一個模組中，以 jar 包的形式提供實現。

所以如果你想要使用 IOC 容器的方式獲取例項時只需要在你的應用中額外加入這個 jar 包即可。

<dependency>
    <groupId>top.crossoverjie.opensource</groupId>
    <artifactId>cicada-ioc</artifactId>
    <version>2.0.0</version>
</dependency>

如果不使用則是預設的 CicadaDefaultBean 實現，也就是每次都會建立物件。

這樣有個好處：

當你自己想實現一個 IOC 容器時；只需要實現 cicada 提供的 CicadaBeanFactory 介面，並在你的應用中只加入你的 jar 包即可。

其餘所有的程式碼都不需要改變，便可隨意切換不的容器。

當然我是推薦大家使用 IOC 容器的（其實就是單例），犧牲一點應用啟動時間帶來後續效能的提升是值得的。

總結

cicada 的大坑填的差不多了，後續也會做一些小功能的迭代。

還沒有關注的朋友趕緊關注一波：

PS：雖然沒有仔細分析 Spring IOC 的實現，但相信看完此篇的朋友應該對 Spring IOC 以及 SpringMVC 會有一些自己的理解。

你的點贊與分享是對我最大的支援