一、控制反轉（IoC） ASP.NET Core在啟動以及後續針對每個請求的處理過程中的各個環節都需要相應的組件提供相應的服務，為了方便對這些組件進行定製，ASP.NET通過定義介面的方式對它們進行了“標準化”，我們將這些標準化的組件稱為服務，ASP.NET在內部專門維護了一個DI容器來提供所需的服 ...
一、控制反轉（IoC）
ASP.NET Core在啟動以及後續針對每個請求的處理過程中的各個環節都需要相應的組件提供相應的服務，為了方便對這些組件進行定製，ASP.NET通過定義介面的方式對它們進行了“標準化”，我們將這些標準化的組件稱為服務，ASP.NET在內部專門維護了一個DI容器來提供所需的服務。要瞭解這個DI容器以及現實其中的服務提供機制，我們先得知道什麼是DI（Dependence Injection），而一旦我們提到DI，又不得不說IoC（Inverse of Control）… [閱讀全文]
二、依賴註入（DI）
IoC主要體現了這樣一種設計思想：通過將一組通用流程的控制從應用轉移到框架之中以實現對流程的復用，同時採用“好萊塢原則”是應用程式以被動的方式實現對流程的定製。我們可以採用若幹設計模式以不同的方式實現IoC，比如我們在上面介紹的模板方法、工廠方法和抽象工廠，接下來我們介紹一種更為有價值的IoC模式，即依賴註入（DI：Dependency Injection，以下簡稱DI）…[閱讀全文]
三、服務的註冊與提供
在採用了依賴註入的應用中，我們總是直接利用DI容器直接獲取所需的服務實例，換句話說，DI容器起到了一個服務提供者的角色，它能夠根據我們提供的服務描述信息提供一個可用的服務對象。ASP.NET Core中的DI容器體現為一個實現了IServiceProvider介面的對象…[閱讀全文]
四、構造函數的選擇與服務生命周期管理
ServiceProvider最終提供的服務實例都是根據對應的ServiceDescriptor創建的，對於一個具體的ServiceDescriptor對象來說，如果它的ImplementationInstance和ImplementationFactory屬性均為Null，那麼ServiceProvider最終會利用其ImplementationType屬性返回的真實類型選擇一個適合的構造函數來創建最終的服務實例。我們知道服務服務的真實類型可以定義了多個構造函數，那麼ServiceProvider針對構造函數的選擇會採用怎樣的策略呢？[閱讀全文]
五、ServiceProvider實現揭秘 【總體設計 】
本系列前面的文章我們主要以編程的角度對ASP.NET Core的依賴註入系統進行了詳細的介紹，如果讀者朋友們對這些內容具有深刻的理解，我相信你們已經可以正確是使用這些與依賴註入相關的API了。如果你還對這個依賴註入系統底層的實現原理具有好奇心，可以繼續閱讀這一節的內容…[閱讀全文]
六、ServiceProvider實現揭秘 【解讀ServiceCallSite 】
通過上一篇的介紹我們應該對實現在ServiceProvider的總體設計有了一個大致的瞭解，但是我們刻意迴避一個重要的話題，即服務實例最終究竟是採用何種方式提供出來的。ServiceProvider最終採用何種方式提供我們所需的服務實例取決於最終選擇了怎樣的ServiceCallSite，而服務註冊是採用的ServiceDescriptor有決定了ServiceCallSite類型的選擇。我們將眾多不同類型的ServiceCallSite大體分成兩組，一組用來創建最終的服務實例，另一類則與生命周期的管理有關…[閱讀全文]
七、ServicePrvider實現揭秘【補充漏掉的細節】
到目前為止，我們定義的ServiceProvider已經實現了基本的服務提供和回收功能，但是依然漏掉了一些必需的細節特性。這些特性包括如何針對IServiceProvider介面提供一個ServiceProvider對象，何創建ServiceScope，以及如何提供一個服務實例的集合。…[閱讀全文]
參考頁面：http://qingqingquege.cnblogs.com/p/5933752.html
