資訊專欄INFORMATION COLUMN
摘要：設想在未來我們為的構造函數新增字段那么上述代碼將修改為如果的初始化耗時很長，將影響構造函數的后續初始化工作。上述在構造函數里直接初始化的過程，屬于主動初始化依賴對象，二者耦合度高，不方便測試。調用方使用對進行依賴注入。
最近接觸了幾個比較大的Java項目，其中常常存在Bean之間的依賴，例如在某服務啟動前要初始化各類詞典，主要方式有顯式聲明Bean和隱式注解注入2種，本文著重介紹后一種。
1. 依賴注入簡介 首先我們定義“依賴”是什么：如果在Class A中有Class B的實例，則稱A依賴B。
現在我們來構造一個依賴：
public class UserDao {
DBConnection conn;
public UserDao() {
// 先初始化數據庫連接
conn = new DBConnection();
}
}
上述代碼中，UserDao即對DBConnection存在依賴。但這樣構造依賴存在如下問題：
(1) 耦合度高。設想在未來我們為DBConnection的構造函數新增字段name,那么上述代碼將修改為：conn = new DBConnection();
conn = new DBConnection(String name);
(2) 如果DBConnection的初始化耗時很長，將影響構造函數的后續初始化工作。
上述UserDao在構造函數里直接初始化DBConnection的過程，屬于主動初始化依賴對象，二者耦合度高，不方便測試。如果被依賴對象事先就初始化好了，直接供給本Class調用，則稱之為依賴注入。例如上述代碼可改寫為如下：
public class UserDao {
@Autowired //依賴注入
DBConnection conn;
public UserDao() {
}
}
要使注入生效，我們還需要在DBConnection中添加Bean標識Component
@Component //將類標識為Bean
public class DBConnection {
public DBConnection() {
init(); //初始化工作
}
}
同時，為了讓Bean的標識被探測到，我們還需要在xml配置文件中添加自動掃描：
到此處相信讀者大致了解其注入原理：
將一些初始化詞典、數據庫連接的類添加諸如@Component的標識，使之成為Bean。
Spring做自動掃描記錄下這些Bean。
調用方使用@Autowired對Bean進行依賴注入。
此處我將這3步分別命名為：服務Bean化、自動掃描、依賴注入。接下來我將詳細介紹這3部分。
事實上我們可以在任何情況下使用@Component標識需要被"Bean化"的服務。但不久我們會發現，其他更有水平的代碼里會有更多富于變化的標識，例如：@Repository、@Service和@Controller。這是怎么回事？設想我們現在有加載本地詞典的類A，本地詞典監控類B，二者有明顯區別：前者的功能視數據訪問，后者則是監控服務，我們更愿意對標識做更精細化的區分，具體如下：
@Repository是為DAO(數據訪問)特制的聲明，將一個類聲明為Repository意味著該類主要功能是數據讀取、DB訪問。
@Service則聲明該類為服務性質的Bean，例如上文中的詞典監控服務，還有許多無關數據操作的功能性初始化類，都應該被標識為Service。
@Controller聲明標志著一個類是SpringWeb的MVC控制器，主要負責MVC之間的操縱。另一個類似的聲明是@RequestMapping，將URL映射為一個方法。
以上3個新的聲明均為@Component的子集，因此僅僅使用@Component也不影響后續的掃描和注入過程。但在現實生活中，其實只有很少的場合我們需要用到@Component，例如無法給類做清晰的定位時。
3. 注解掃描注意到上文中的這段自動掃描，它的包名其實可以根據用戶需求做出更改。例如：現在我有一個判斷query是否為臟詞的服務A，它僅依賴注入了自動加載臟詞詞典的類B。此外，項目中還存在訪問數據庫的類C，但我們沒有為數據庫配置訪問信息。當我們將注解掃描范圍設置為整個項目時，啟動服務A將產生問題。
解決方案是縮小自動掃描范圍，使得Spring僅掃描B而不掃描C。具體做法是增加掃描過濾器, Spring支持正則Regex和AspectJ兩種表達式的方式進行掃描過濾。
例如：
