? IoC(Inversion of Control)是一個很寬泛的概念，對于我們常說的IoC容器（如spring)所做的工作,一個更加準確一些的說法是依賴注入(Dependency Injection), 即容器將一個對象所依賴的其他對象push到該對象中,而不是該對象從外界環境pull相關的依賴對象. 不過, 細究起來這種依賴注入仍然只是DI的一種特殊形式, 可以將它稱之為data dependency injection, 因為IoC容器所許諾的是: "啊哈, 當我們需要對象A的時候,它就在這兒". 雖然IoC容器管理的不僅僅是數據,而是具有行為的對象,但是如果要讓這些行為具體發生, 我們仍然需要額外的調用步驟.
? 對于一個自動觸發behaviour的系統, 我們一般將之稱之為引擎(Engine). 例如工作流引擎在處理完本步驟的業務邏輯之后會自動觸發流程流轉操作. 一個引擎對于我們的承諾是: "當我們需要某個behaviour的時候, OK, 它會在適當的時候發生的". 對于一個軟件開發框架或者更宏大的軟件開發平臺而言, 如果我們以業務邏輯為主體來審視整個程序運行過程, 則它們的核心價值也在于在適當的時候將適當的操作Inject到業務邏輯中. 對于目前所謂的軟件開發平臺而言, 除了工作流的內容之外, 一個主要部分就是CRUD(Create/Read/Update/Delete) Ready. 一個開發平臺的優劣往往直接體現在它在多大程度上能夠將CRUD操作剝離出主體程序邏輯, 這不僅僅涉及到數據庫存取操作, 同時還包含界面交互, 數據邏輯關聯等.
? 除了引擎,框架,平臺等應用層面的實現之外, AOP(Aspect Oriented Programming)在語言層面為behaviour注入也提供了一種特定的實施手段. 在AOP的概念中, 往往作為切點的函數被認為是基礎的部分, 而interceptor是在基礎藍圖上的一種擴展. 這也體現在基礎函數定義了當時執行環境中可以訪問的狀態變量(參數/屬性),而interceptor則依附于pointcut處所能得到的狀態變量, 它本身一般并不維護獨立的狀態變量(不產生也不消滅狀態變量). 從數學上看, base function和interceptor之間構成一種對偶(dual)關系, 當我們的關注重點轉移到interceptor上來之后, 它本身也應該具有完整的業務語義, 這需要對AOP的執行過程做小小的偏置處理.
? 在witrix平臺的BizFlow設計中,BizFlow是通過類似AOP的方法作為CRUD操作的Filter實現的, 但是從bizflow本身的配置文件來看,它可以構成一個完整的業務描述, 而CRUD成為某種自動注入的behaviour.例如對于新增操作, BizFlow中的配置可以如下
? <action id="Add-default">
? </action>
雖然沒有寫任何代碼, 新增操作(包括從request中讀取操作并做有效性校驗等操作)是自動進行的. 我們也可以在新增前和新增后分別執行一些操作
? <action id="Add-default">
??? <source>
????? some operation before add
????? <biz:Proceed/>
????? some operation after add
??? </source>
? </action>
與AOP中的常見做法不同, 這里并沒有明確定義新增前和新增后這樣的切點, 而只是定義了Add-default這樣一個action. 在BizAction的source段可以執行任何tpl代碼, 而tpl代碼的執行上下文可以看作一個Map, tpl代碼執行過程中可以獲取變量, 也可以設置任意變量, 因而bizFlow擁有對于狀態空間的完全的控制權.