這個設計原則,你認同嗎?

前言

我們都知道依賴注入的方式常見的主要有三種

  1. 構造函數注入
  2. 屬性注入
  3. 接口注入

在大名鼎鼎的Spring框架中大量使用屬性注入的方式,屬性注入的方式寫起來那是真的爽;而在Asp.NetCore中則不支持屬性注入,如果不使用第三方庫,我們就只能在構造函數上寫上一堆參數,比較麻煩,有些人是非常討厭這種注入方式,選擇使用第三方IOC框架。

思考一個問題

Asp.Net Core框架哪哪都牛逼,可偏偏不支持很多人崇尚的屬性注入呢?如果你還在期待什麼時候支持這一特性,可能會讓你失望了。但也不排除社區呼聲很高的情況下支持這個特性。但這屬性注入它不是推薦的方式。

顯式依賴關係

方法和類應顯式要求正常工作所需的任何協作對象。 我將此稱為顯式依賴關係原則。通過類構造函數,類可以標識其實現有效狀態和正常工作所需的內容。 如果定義的類可供構造和調用,但僅在具備特定全局組件或基礎結構組件時正常工作,則這些類對其客戶端而言就不誠實。 構造函數協定將告知客戶端,它只需要指定的內容(如果類只使用無參數構造函數,則可能不需要任何內容),但隨後在運行時,結果發現對象確實需要某些其他內容。

若遵循顯式依賴關係原則,類和方法就會誠實地告知客戶端其需要哪些內容才能工作。 遵循此原則可以讓代碼更好地自我記錄,並讓代碼協定更有利於用戶,因為用戶相信只要他們以方法或構造函數參數的形式提供所需的內容,他們使用的對象在運行時就能正常工作。

總結

如果你你贊成這一設計原則,那就不要折騰地去實現屬性注入了,不僅僅是在依賴注入這一場景,在其他時候我們應該遵循這一原則地初衷,請盡量把你方法或類中依賴的對象大大方方的顯示聲明出來。

您怎麼看待這個問題?

引用:

  1. //docs.microsoft.com/zh-cn/dotnet/architecture/modern-web-apps-azure/architectural-principles#explicit-dependencies