云自無心水自閑

Tapestry IoC容器從歷史上來說，是從從HiveMind繼承發展而來，但是HiveMind和目前大紅大紫的Spring都不能滿足Tapestry的一些特定的需求，所以全新開發了一套IoC的容器。
其核心思想就是使用Java代碼自身來解決依賴注入而不是由Xml之類的配置文件來完成，這和Guice的思想是非常相似的，Lewis也承認從Guice那里借鑒了不少。
另外需要說明一下的是，Tapesty還從中國的一個非常古老但又充滿哲理的游戲--圍棋中借鑒了一些術語和思想。大意是圍棋中經常要把棋子走的輕盈(Lightness)，讓每個棋子都能盡量地高效。編程也一樣要輕量(Lightness)。

IoC容器中使用的一些概念，充分理解這些概念會對Tapesty IoC容器有一個總體上的感性認識。

Tapestry IoC中的最基本的組成單元是服務(Service)。服務一般由一個接口和一個接口的實現組成。每個服務都有一個全局唯一的標識(ID)。
數個或者多個服務組成一個模塊。模塊中會包括一個模塊定義類，在這個類里面有一系列的靜態或者成員方法
，用于定義服務、裝飾服務、或者添加配置項。
這個類中的方法定義服務，并同時負責實例化服務的實現類。
這些方法被稱為：服務創建 (build) 方法。

注冊表(Registry) 是外部世界與服務和模塊交互的媒介。通過注冊表，使用服務的ID或者服務接口，才有可能獲得一個服務（服務ID是大小寫不敏感的，這是Tapestry的一個隨處可見的特性）。

服務可以由服務裝飾方法進行裝飾(decorate)。這些裝飾方法會創建攔截器(interceptor)來包裝核心的服務實現，
在外面添加諸如日志、權限檢查、數據庫事務之類的行為。攔截器需要實現同樣服務接口，這實際上就是一個裝飾模式的應用。

下面是關于服務的一個很重要的概念：配置(Configuration)。
在Tapestry的AppModule.java中最常見的是兩類方法，一類是前面剛剛介紹過的服務創建方法，一般是以build開頭的。另一大類就是添加配置的方法了，一般是以contribute開頭。
服務可以根據配置項靈活配置，配置的數據結構可以是Map、集合或者是有序列表。
服務自己定義允許什么類型的配置項可以被添加到配置中，Tapestry中把添加配置項的動作稱之為貢獻(Contribute)。
配置可以由一個或者多個模塊分別貢獻而成。通過調用服務貢獻方法(Service Contributor Methods)來把配置對象添加到配置中。

服務的狀態演變：
服務只有在需要的時候才會被實例化。在這里，“需要”的意思是服務的某個方法被調用了。開始的時候，從外界來看，服務只是一個實現了服務接口的代理。
當這個代理的方法第一次被實際調用的時候，完整的服務（也就是服務的實現類）才會真正地被構造。
并且這個構造過程是線程安全的。

實例化服務、進行依賴注入、裝飾服務這就是服務實現(Realization)的所有組成部分。通過這三步一個服務才從虛擬狀態(只是一個代理)轉換成真實狀態(完全的實例化，等待被使用了)。

服務的范圍：服務的缺省范圍是單例的，另外也可以與當前線程綁定.

依賴項是服務實現類所需要的其他服務。依賴項可以由服務創建方法通過構造函數、方法參數注入進來。
注入點可以是類成員屬性、方法參數、或者構造函數參數。通常使用注解來指定注入的類型。