Autofac.pptx

1. Autofac IoC / DI 框架 Allen liu 2022-06-01
2. 大綱 01 概念 IOC / DI 02 Autofac 簡介 / 應用 / 實例 03 參考 / 提問
3. IOC: Inversion of Control 控制反轉 DI: Dependency Injection 依賴注入 01 概念 - IOC / DI 設計原則實作
4. 控制反轉 (Inversion of Control) 好萊塢原則 (Hollywood Principle) Don‘t call us, we‘ll call you 01 概念 - IOC / DI
5. 控制反轉 (Inversion of Control) vs. SOLID=> 依賴反轉 (Dependency Inversion Principle) 01 概念 - IOC / DI 反轉依賴關係反轉控制流程
6. 01 概念 - IOC / DI 依賴反轉 (Dependency Inversion Principle) 定義：高階模組不應依賴低階模組，兩個都應該依賴在抽象概念上抽象概念不依賴細節，而是細節依賴在抽象概念。「話不能說的太死，盡量講一些概念性的東西」
7. 01 概念 - IOC / DI 依賴反轉 (Dependency Inversion Principle)
8. 01 概念 - IOC / DI 反轉依賴關係反轉控制流程 IOC X DIP
9. 01 概念 - IOC / DI 反轉依賴關係 IOC + DIP 反轉控制流程 = 鬆散耦合系統 DI
10. 01 概念 - IOC / DI 依賴注入 ( Dependency Injection ) 將所需的依賴實例，注入到高階模組中。 1. 建構元注入 ( Constructor Injection ) 2. 設值方法注入 ( Setter Injection ) 3. 介面注入 ( Interface Injection )
11. 01 概念 - IOC / DI 依賴注入 ( Dependency Injection ) 將所需的依賴實例，注入到高階模組中。 1. 建構元注入 ( Constructor Injection ) 2. 設值方法注入 ( Setter Injection ) 3. 介面注入 ( Interface Injection )
12. IOC: 控制反轉。 DI: 依賴注入。好萊塢原則 ( Hollywood Principle ) SOLID Dependency Inversion Principle ( DIP ) 依賴反轉 Open / Close Principle ( OCP ) 開放/封閉原則 …etc. 01 概念 - IOC / DI
13. 01 概念 - IOC / DI 反射 (Reflection) .Net 提供的一個幫助類庫，可以讀取並使用 Metadata。 IoC / DI 容器 ( Container ) 透過『反射 (Reflection) 機制』，『自動生產』物件，動態生成實例，或由配置文件尋找依賴關係，描述該如何建構實例、或檢查是否該為當前模組注入依賴，將其提供給所需模組，並管理該物件整個生命週期的超級自動化工廠。
14. IoC 容器 Autofac 是一款 .NET IoC 容器. 它管理類別之間的依賴關係, 從而使應用在規模及復雜性增長的情況下依然可以輕易地修改. 它的實現方式是將常規的 .net 類別當做元件處理 . 安裝-透過 NuGet 相關內容可參考官網 02 Autofac - 簡介
15. 要註冊到 Container 的類別。 Component：基本上就是你和 DI Container 要東西的時候，他會 new 給你的類別 Service： Component 會提供的服務，基本上會是 interface 告訴 ContainerBuilder 什麼 Service（Interface）對應到什麼 Component（Interface 實作的 Class） 02 Autofac - 應用 Resolving Build Registering
16. 02 Autofac - 應用
17. 02 Autofac - 應用
18. Autofac 如何整合 Asp .net Mvc Autofac.Integration，提供了幾個 helper 方便我們整合 Autofac 和 Mvc DependencyResolver Mvc 只能夠實例化預設無參數的建構子， IOC/DI Container 有註冊 Service / Component 知道需要注入的 Component。 02 Autofac - 應用
19. * Autofac 抽換 Log 套件 Demo * 旺宏專案應用使用上並不難，難的是如何在不同的情境使用它。 Release Notes ...etc. 02 Autofac - 實例
20. 鄭中勝 - 控制反轉 IoC 與依賴注入 DI Alan Tsai - MVC 5 / IoC基本概念介紹物件導向程式設計基本原則 Autofac 基本介紹 Autofac 筆記 Autofac 中文文檔 .NetCore DI 04 參考 / 提問
21. S => Single responsibility principle 單一職責 Don't Over Design - e.g. 駕駛只要知道汽車怎麼開不用知道汽車怎麼組裝。 01 概念 - IOC / DI

Hinweis der Redaktion

設計原則。指導行動的“最高標準”，“一套標準”。
實作。實際操作。實地操作。實際製作
IOC的原理就是基於好萊塢原則，所有的組件都是被動的（Passive），所有的組件初始化和調用都由容器負責。解除了高階模組主動對低階元件實例的依賴
舉例子來講
網咖遊戲都是預先安裝好給你玩的版本也是老闆選擇的，今天要換版本或是換遊戲，都由老闆抽換後，你直接玩就好。
麥當勞菜單都是固定的你只能點當季餐點，只要點餐就好不用管餐點從哪來。
補充不用講 (但比較要注意的一點是如果這時候還是用 NEW 的方式，沒利用到 DI 則是有照 IOC 但沒照 DIP 的狀況，後續會提到 )
再來是很容易搞錯的控制反轉與依賴反轉

反轉控制流程
倒轉的則是實例依賴物件 (don‘t call us, we‘ll call you)

---

高階模組不應該依賴於低階模組，兩者都該依賴抽象。
抽象不應該依賴於具體實作方式。具體實作方式則應該依賴抽象。
那什麼是依賴抽象呢，簡單講就是利用抽象，達到鬆耦合 (Loose coupling) 目的
沒有彈性的寫法在
_定義（Declare）_參數的瞬間就_已經決定了_這個參數的具體使用方式。因此和一般的程式flow是一樣的，重上到下

使用interface的寫法，是在
_實例（也就是new()）的時候才決定具體的使用方法。因此它的flow是到要用的時候才會new，所以是_依照後面要什麼來控制的。
IOC 與 DIP 是兩種設計原則，講的是不同事情，雖然 IOC 解除了高階模組主動對低階元件的實例方式，
卻解除不了高階模組對低階模組的依賴關係。
所以我們就要藉由兩種設計原則，由服務容器 (IoC 容器) 透過 “依賴注入”，給予高階模組所需得具體實例

取代傳統的主動建立實例

高階模組，依賴於抽象，而非低階模組。
但要使用該抽象的 (低階模組) 時，

不用也不需要知道是哪種具體產品
不再自己實例具體產品，而是服務容器會提供給他。

補充
IoC/DI ，並非實現 "DIP" 的唯一解，
還有工廠方法模式 (Factory Method Pattern)、服務定位模式 (Service Locator Pattern)，
以及各種的建立型模式 (Creational Pattern)…，皆可以消除實例具體產品 (插件 Plugin) 的依賴關係。
那什麼是di 呢將所需的依賴實例，用注入的方式，注入到高階模組中。分為三個時機點可以注入
DI 可以在這幾個時機使用，但以 MVC專案來說不支援有參數的建構子，這部分會由接下來講到的 IOC 容器框架解決。
所以我們知道 IOC DI 很好的實現了以下原則，讓程式鬆耦合
但是這邊遇到了個問題，DI 我們可以用手動的方式達到，但是其實還是_不彈性_。
舉例來說，當我要切換實作的時候，還是需要改code並且重新編譯。因此本質上還是沒有彈性的效果。

所以又有了 IoC 容器來輔助我們 (又稱：服務容器 Service Container)，

大部分框架的 IoC 容器，幾乎都透過『反射 (Reflection) 機制』，
來動態生成實例、或由配置文件尋找依賴關係，
描述該如何建構實例、或檢查是否該為當前模組注入依賴 …。

因此容器，通常會有個 bind (或 register、config …etc.) 的函數，
供註冊依賴關係、或告訴容器: 何種情境需要該實例。

再來，通常也會有有個 make (或 create、resolve …etc.)，
讓容器解析物件，或實例已綁定之物件。

是組裝 & 配置元件，透過依賴注入 (Dependency Injection)，
提供所需服務給模組的地方。
比較常見的.Net DI Container做效能和功能的比較
在一個龐大且複雜的系統中要將資料來源由查詢資料庫改成從檔案讀取資料，
會影響系統中數百段用到資料查詢來源的程式碼，
現在只需要調整 IOC 對應的 Service Component
實作 IOC DI 容器，其實只要做到這己見事

註冊階段主要是在將Service和Component註冊對應關係，註冊的方式有很多種情境，包含最基本的指定型別註冊、甚至可以直接掃描Assembly根據裡面的內容來做大量註冊的動作。

雖然已經註冊好關係，但有用的是實際的類別。透過Autofac，我只要跟它說我需要一個實際的物件，而且必須是XX的類型。容器會根據你所註冊的關係，將其 Build 實體化之後返回。

---

再來是一些管理這些實例生命週期的方法

--- 以下為補充
以往用new的方式建立物件，使用完畢後，即使不釋放(dispose)該物件，也會有記憶體回收機制來幫忙處理。但使用Autofac處理相依性後，原本new的動作將交由Autofac來處理，所以Autofac會主導此物件的生命週期，原本的記憶體回收機制就不會干涉，物件的釋放由Autofac全權處理。講白話就是，假如沒有釋放Autofac建立的物件，最終將會耗盡所有記憶體。

但也不必太擔心，Autofac本身有提供很多管理物件生命週期的方式，讓物件和記憶體的使用更有效率。以下就簡單介紹一下最基本的用法，使用Using搭配BeginLifetimeScope()來達到效果，在Using的結尾處，括號內的物件都會自動被釋放(dispose)。
這邊就是實際使用時的步驟，主要就是要藉由 IOC DI 容器的方法，註冊介面
再藉由 IOC DI 容器來提供實例
剛剛開始所講到的，其實一般都是藉由建構子注入依賴，
但一般的 MVC 只能夠實例化預設(無參數)的建構子，
因為它不知道每一個參數是對應到什麼class，因此沒有辦法做下去。

那這邊利用到的是 MVC 專案所提供的接口 IDependencyResolver 允許客製化 IOC 解析器

我們就能藉由 Autofac DependencyResolver 實例化，就能在建構子時注入

---補充

第一個當然是IDependencyResolver的實作，方便使用Autofac作為Mvc的DI
ContainerBuilder有多一個RegisterControllers的擴充方法，只要把Controller所在的Assembly給他，它就會幫我們把所有Controller都註冊成為Component
之前講註冊Service的時候，沒有提到Component的Lifetime Scope(這方面比較細部因此不會介紹，有興趣可以看文件)，在裝了這個Integration，會多一個Lifetime Scope是InstancePerHttpRequest，表示每一次Request都是新的物件
有提供能夠動態注入ModelBinder到Mvc
提供一個Autofac的Module方便注入Http相關 - 因此要取得像Session、Request等變的簡單
提供注入Property到View和ActionFilter裡面
這邊只是引導一個開頭，打開書籤講解

Autofac 簡易 Demo
1. 這是個普通的 mvc 專案，首先看到參考，跟其他套件安裝上比較不一樣的是，除了主要的 autofac 還必須包含像是 mvc 或 api 的整合庫
2. 接著這裡簡單實作了兩種 log 一種是作初始專案較簡易的 log 另一個則是用 nlog 在 release 時更多面向的 log
3. 則會藉由在 Global 時，判斷狀況由 ioc 提供不同的實作，

專案上更進階的使用 autofac
1. 一樣首先註冊ioc，參考內一樣是藉由整合庫整合 api 專案，一樣是去使用 build 好的容器
AutofacModule 當要註冊 IMessage 這個抽象介面的時候，Autofac DI Container 將會幫我們產生一個 ConsoleMessage 類別的物件。
RegisterType 註冊類別時使用
ResolveNamed 介面實作了多個類別，Resolve<>() 時希望透過參數指定傳回不同類別。
利用介面實作不同的 write 的關係

Autofac.pptx

Du liest eine Vorschau.

Hier ansehen

Autofac.pptx

Weitere Verwandte Inhalte

Aktuellste (20)

Empfohlen (20)

Autofac.pptx

Hinweis der Redaktion