IoC概要

控制反轉基本上說的是功能調用者與功能實現者之間應該如何交互，即兩者之間沒有直接的強耦合（調用者new一個被調用者），而是都依賴同一個抽象，這個抽象規定了兩者交互的接口。反轉的意思是實現了依賴倒置，在程序中高層不是根據低層的接口來寫調用，而是倒過來，高層根據須要定義接口，低層向上負責實現這個接口。這體現了自頂向下的設計思路和自底向上的實現方法，使軟件代碼具備天然的可讀性，以及關注點的分離。

IoC容器是實現IoC的框架，具體包括了接口與實現的關係配置功能和獲取實現對象的功能，其中獲取實現對象的功能大致對應了設計模式中的工廠模式，下面簡要分析對比一下原生態new調用，工廠模式調用，和IoC容器調用：

爲了對比方便，在分析原生態調用以前先假設一個前提，那就是功能被某個具體的類實現了。直接調用有最好的性能，但可維護性和可測試性不好，好比想要修改一個功能的實現，有2種實現方法A和B，A是一個巨大的改變，也就是適合於新寫一個類來實現，B是一個較小的改變，能夠直接修改類的內部結構。假如用A方案，而系統又有多處引用，甚至還須要注意構造函數及其參數的變化，那麼意味着多個修改量，這違背了TRY原則，對開發是一個負擔。假如使用了B方案，那就要注意內部實現的改變是否會影響外部環境，是否有使修改不封閉的地方。而可測試性就沒必要多說了，由於是直接new的，因此沒法Moq，致使沒法完美的作單元測試。

當直接用工廠模式時，須要先作抽象，即把功能代碼分紅抽象和實現兩部分，功能調用者調用工廠提供的方法得到具體的實現對象，這確保了系統是面向接口編程的，幫助編程者寫出高內聚低耦合的邏輯。同時也引起了一些問題，好比可能有較多的工廠類須要維護，功能調用者與工廠類之間又有耦合，假如用抽象工廠模式來解耦，又須要增長配置文件的內容。

使用IoC容器能夠很是方便的定義符合某個接口的實現對象的獲取策略，可以對對象的生命週期作配置和管理，而無需編寫和維護工廠代碼，擁有最佳的可維護性和可測試性。