第69篇 DI依賴注入

似梦亦非梦發表於2024-12-07
依賴注入

1.相關基本概念

1.1 類和物件

類是一個靜態的概念，類本身不攜帶任何資料。當沒有為類建立任何物件時，類本身不存在於記憶體空間中。

new 例項化的過程
宣告引用；
使用new關鍵字建立類的物件並對其初始化；（分配記憶體空間）
將引用指向類的物件。

解除依賴的思想是如何產生的？
(1)原始社會里，沒有社會分工。須要斧子的人(呼叫者)僅僅能自己去磨一把斧子(被呼叫者)。相應的情形為:軟體程式裡的呼叫者自己建立被呼叫者。

(2)進入工業社會，工廠出現。斧子不再由普通人完畢，而在工廠裡被生產出來，此時須要斧子的人(呼叫者)找到工廠，購買斧子，無須關心斧子的製造過程。相應軟體程式的簡單工廠的設計模式。

(3)進入“按需分配”社會，需要斧子的人不需要找到工廠，坐在家裡發出一個簡單指令:須要斧子。斧子就自然出如今他面前。依賴注入。

1.2 控制反轉 IoC （Inversion of Control）

23種設計模式6個基本原則

  • 1.單一職責（一個方法或一個類只做一件事，為了模組內高內聚）
  • 2.迪米特法則（也叫最少知道原則，為了模組間低耦合）
  • 3.里氏替換（就是繼承原則，子類可以無縫替代父類。很好的符合了開閉原則）
  • 4.依賴倒置（類之間的依賴透過介面實現，低耦合的同時對擴充套件開放）
  • 5.介面隔離（即把單個複雜介面拆分為多個獨立介面，與上條共同實現面向介面程式設計）
  • 6.合成複用原則（即儘量使用合成/聚合的方式，而不是使用繼承。主要為了防止繼承濫用而導致的類之間耦合嚴重。記住只有符合繼承原則時才用繼承）

高階模組不應該依賴於低階模組;兩者都應該取決於抽象

什麼是控制反轉
你把程式裡的一個寫死的變數改成從配置檔案裡讀取也是一種控制反轉（由程式控制反轉為由框架控制），你把這個配置改成使用者UI介面的一個輸入文字框由使用者輸入也是一種控制反轉（由框架控制反轉為由使用者自己控制）。

  • 是一種設計原則，最早由Martin Fowler提出，因為其理論提出時間和成熟時間相對較晚，所以並沒有被包含在GoF的《設計模式》中。
  • 對依賴的控制，從自己，轉到自己的呼叫者上。

1.3 依賴注入 DI（Dependency Injection）

DI 和 IoC的關係

  • 實現IoC的其中一種設計方法，
  • 依賴的物件注入到呼叫者，你不應該自己建立它，而是應該透過建構函式由你的呼叫者給你——容器

常用的框架有哪些

  • 微軟 core 自帶的 DI
  • Autofac：貌似目前net下用的最多吧
  • Ninject：目前好像沒多少人用了
  • Unity：也是較為常見

三種注入方法

  • 建構函式注入（遵循顯式依賴原則）

      public class StudentService : IStudentService
  	{
  		private readonly IStudentRepository _studentRepository;
  		/// 
  		/// 構造注入
  		/// 
  		/// <param name="studentRepository"></param>
  		public StudentService(IStudentRepository studentRepository)
  		{
  			_studentRepository = studentRepository;
  		}
  	}

  • 屬性注入

      public class TeacherService : ITeacherService
  {
  	
  	
  	
  	public ITeacherRepository TeacherRepository { get; set; }
  	public string GetTeacherName(long id)
  	{
  		return TeacherRepository?.Get(111).Name;
  	}
  }

  要使用這種屬性注入，在註冊該屬性所屬類的時候，需要使用PropertiesAutowired()方法額外標註，如下：
  builder.RegisterType<TeacherService().PropertiesAutowired();

  • 方法注入

三種生命週期，注意要保持一致

  • AddTransient
    每次注入或請求時都會建立轉瞬即逝的服務.

  • AddScoped
    是按範圍建立的,在Web應用程式中,每個Web請求都會建立一個新的獨立服務範圍.

  • AddSingleton
    每個DI容器建立一個單例服務,這通常意味著它們在每個應用程式只建立一次,然後用於整個應用程式生命週期.

舉例，場景說明（自動售貨機）：

  • 容器是一個自動售貨機，元件是放在裡面的在售商品，服務是商品的出售名稱。
  • 把商品（專案裡的具象物件）放入自動售貨機（容器）上架的過程叫註冊；
  • 註冊的時候會給商品貼上標籤，標註該商品的名稱，這個名稱就叫服務；
  • 我們還可以標註這個商品的適用人群和過期時間等（生命週期作用域）；
  • 把這個包裝後的商品放入自動售貨機後，它就變成了在售商品（元件）。
  • 當有顧客需要某個商品時，他只要對著售貨機報一個商品名（服務名），自動售貨機找到對應商品，丟擲給客戶，這個拋給你的過程，就叫做注入你；
  • 而且這個售貨機比較智慧，丟擲前還可以先判斷商品是不是過期了，該不該拋給你。

2.為什麼要使用依賴注入

image

3.依賴注入的步驟

image

4.DI其他方面使用———— AOP

相關文章